Search text kbd entry fails; viewer then fails to re-start

[jpaul]

Hi,
I find that keyboard entry of text in the input text field for
search & find fails after I have been using viewer a while;
I focus the input field but keys on the keyboard
do not get echoed; backspace to remove previous contents works though.
Unable to conduct a search I exit the viewer but when I try and re-start
from either command line or start menu viewer fails to start with no error message.
A re-boot (windows xp) enables viewer to start.
I have re-installed the viewer once, with latest available version but problem
returned.

I had been using the viewer for 1 year without any issues.

Neither the event viewer nor command line launch of the viewer
told me why the re-start fails - is there somewhere else to look ?
Are there registry locations I should potentially clean.

Regards, Paul

ps I have not tried a paste command as a means to enter data in the search text box

[Stefan - PDF-XChange]

Hello Paul,

Just to be sure - can you please open the Viewer, and go to Help -> About, and make sure that it says build 201 in there?

Best,
Stefan

[jpaul]

Stefan,
Thanks, it actually says version 2.5 (200) so I guess there
was a newer update.

I did discover that by launching from the command line in install directory
and specifying settings from a non-registry location
[per topic https://forum.pdf-xchange.com/ ... ttings.dat]
PDFCCview.exe /usep mysettings.dat
enabled viewer to start without needing a re-boot,
however setting file did not appear at
"\%UserProfile%\PDF-XChange Viewer Settings\settings.dat
as manual suggests.

I will run the viewer in this way and see if the text entry problem recurs.
(some kind of registry corruption ?)
However running in this way seems to prevent the auto-restore mechanism from working in a new session (but recently accessed files list is preserved )

Regards, Paul

[Stefan - PDF-XChange]

Hello Paul,

I haven't seen other reports of problems with registry corruption, so I would assume that maybe some of the cleaning applications you used caused this, but yes - it's possible.

I would recommend a new clean install of build 201 - and then launch the viewer and try to reset all settings to default - this should allow the viewer to clean it's own section of the registry, and I believe the problems will disappear.

Best,
Stefan

[jpaul]

Hi,
I believe problem is associated with having multiple pdfCview.exe
processes running, I have killed these and behaviour now seems correct.

I am not sure why multiple sessions start; the XP taskbar was only
showing one session; however in an extended desktop(multiple monitor)
situation, sometimes when opening documents the child file explorer
window does not get drawn in any of monitors and session is then blocked, in which case opening a new document using from the xp file manager
seemed to unlock the session (and give me previous documents)
but I now think the duplicate viewer somehow got invoke here.

Any suggestions welcome.

Cheers, Paul

[Stefan - PDF-XChange]

Hello Paul,

It's possible (through the Viewer's settings) to allow multiple instances of the same to be launched, and then when you do use the command line - you were effectively launching new and new instances.
Usually this should not cause registry corruption, and the very last instance of the Viewer that closes will store it's current set of settings in the registry. What you have experienced is unusual so if you manage to reproduce it with build 201 - do post here the step by step sequence to reproduce and we will see if we can figure out what's happening.

Best,
Stefan

[jpaul]

Hi,
Some more details/theories on this problem (not yet a recipe to reproduce it)

Multiple instances of the viewer are disabled in my preferences; despite this
sometimes when I use explorer context menu (shell integration) to launch viewing of a new document
it apparently fails to communicate with the existing viewer instance (also minimised) and
starts a new viewer (but does not manage to expose/show the new window)
re-opening the new document this will now succeed in the original instance.
but the original instance now shows problem where text entry fails (instance
becomes useless)

I think maybe original instance is uncommunicative since it maybe waiting for
reponse on pending re-loading network document popups.
[theory -issue only happens after a un-hibernate of laptop where
viewer was left minimized, and I try to open a new document without first
maximising it and responding to re-load popup for network documents.]

Regards, Paul

[Stefan - PDF-XChange]

Thanks for this Paul,

Yes - it appears like the un-hibernation and network files could be causing this. We will take a new look into this and advise here in this topic as soon as we have further news.

Best,
Stefan

[Katya - Tracker Supp]

Hello Paul,

It seems that the dev team needs much more time for investigating the issue. We'll try to resolve this case in the next version.
Right now we have created a ticket in our internal system (T# 1451 Waiting for re-loading network document after hibernate) in order to help us to follow your case.
As soon as we have some results we let you know.

Thanks,
Katya

[jpaul]

Katya,
Thanks for the update.
[I acknowledge that I have not sent a recipe to reproduce the problem
I have seen, so it may take some exploration to uncover cause.]

I think that the mechanism to re-load network documents after un-hibernate
should be revised in following manner which may well avoid problem I had.:
one mechanism re-load occurs, is if you move cursor over a document tab
(where it transiently gets focus) Proposal -> reload should only occur when the tab
is actually selected/clicked; since at the moment where I have many network
documents I find myself wasting time waiting for a reload if I accidentally
move pointer over a tab.

Indeed I am intermittently seeing a crash where on focussing tab of un-loaded
document I see

>PDFXCview.exe - Applciation Error
The instruction at ‘0x0092e335’ reFerenced memory at “Ox0000000c’, The memory could not be ‘read’.
Click on OK to terminate the program
Click on CANCEL to debug the program
OK Cancel

I need to figure out how to take a regular snapshot of the open documents;
since when it crashes like this, the memory of documents open from previous
session is not preserved for re-start. (I think I need to quit and re-start viewer regularly to make snapshots)

I will check the forum to see if there is advice on how to collect data
under such a crash.

Regards, Paul

[Stefan - PDF-XChange]

Hello Paul,

We are still working on the ticket and as soon as we have any news - we will let you know. In the mean time I hope you will manage to find a viable workaround!

Best,
Stefan

[jpaul]

Stefan,
Hi, I was not clear.

I meant please consider changing the way in which network documents are
reloaded : do not re-load any documents automatically or when
document tab transiently has cursor focus; wait until user clicks on a
tab and then load document.
Reloading the doc's takes time I often have 5 or so 10MB (each with large index
annotation tables) and taking 20-30s each to load; and I did not want work
to be interrupted by these re-loads. (which also cause focus to be changed
to the re-opened doc)

Additionally (as mentioned) I sometimes have crash when doc's are re-loaded
I could not find any sticky thread that shows whether there are particular
log files or strategy to collect data to send to you (if I cannot
reproduce the problem repeatedly and send you the recipe)

Regards, Paul

[Stefan - PDF-XChange]

Hi Paul,

And thanks for the clarification. Yes that will certainly be taken into account when the ticket above is resolved.

As for collecting logs - not with the default viewer. We have provided some custom builds in the past that do log everything - but only if we are totally unable to reproduce the problem in our own testing. If such a course of action is needed for this case we will let you know.

Best,
Stefan

[jpaul]

Stefan,
I am seeing regular crashes where automatic re-loading of network documents seems to
interfere with other interactive viewing of already open documents.

One inconvenience of crashes is that the restore session reverts to that from the start of
the previous session; other that quitting and re-starting regularly is there an easy way
to get the saved session up to date ?
This issue is discussed a bit in current thread (https://forum.pdf-xchange.com/ ... 35&t=10162)
I can dump the open documents regularly from their registry location
>reg QUERY "HKCU\Software\Tracker Software\PDFViewer\Documents\LastSession" /s
but from this other thread I do not understand whether the portable version
(or just running PDFCCview.exe /usep mysettings.dat)
will provide functionality where session is loaded from an editable text file. ?

Q. Are there clear instructions on format and way to use a text file for session re-load
(as opposed to registry) ?



Regards, Paul

[Stefan - PDF-XChange]

Hello Paul,

I am afraid that the settings.dat file is not a plain text one and I do not know of any such way to store/load/edit sessions via a manually editable file.

And yes - currently sessions are updated at the time the Viewer is closed, so if a crash occurs - the next time the Viewer is started it will resume from the last properly saved session.

Best,
Stefan

[jpaul]

Stefan,
Hi for the potential benefit of others (I am curious no one else has this issue, so bumping it)
the workaround I have adopted is :

PDF-X problems with : text search failing, multiple viewer processes starting and session
not then exiting gracefully with document history; seems
to be associated with session that have come out of hibernation and are automatically
re-loading network documents.

workaround: To enable a reliable history of open documents to be stored need to ensure that artificially
quit and re-start a session before any hibernation so that a re-loadable history is assured, for when
session goes bad.

Cheers, Paul

[Stefan - PDF-XChange]

Hi Paul!

Thanks for the bump and workaround, and yes seems like no one else has reported similar behaviour so maybe it's something specific to your network configuration.

Best,
Stefan