PDF XChange Forum

Hi,

Before Release 328, properties pane was always active on the right side after successive closing and opening of various pdf file.
Since 328 release even if I check "Properties pane" (attached file 1), the properties pane disappears after closing and opening different files.
The issue occurs on my main computer (Dell Precision) with Win 10 x64.
To complete my first analysis of the issue, I verified on my ASUS laptop (WIN 7 x64). The same issue is observed?

Any idea for solve the issue?

Best regards,

Gerard
FRANCE

Hello woinic,

Can you please verify that the "synchronize layout of document panes […]" checkbox is selected, this is available inder preferences (Ctrl+K) > general > tabs and windows > setup: As well, please check that the "Restore last used view of […] panes […]", from Preferences > page display, is set as such: Both of these should be enabled, and all should work well. Please also verify that you are running the latest build 328.2, as we did recently release this point build update.

Kind regards.

Hi Daniel,

I presently use the last release 328.2.
With the 328.1 release, the same issue occurred.
I remember that when I used for the first time the 328.1 release, I decided to remove 328.1 completely and to reinstall the 327 release.
With the 327 release, all is working fine.
Concerning the preferences setup, all checkbox are correctly checked and same as above (Tabs and windows and Page display)

Best regards

Gerard
FRANCE

Hello woinic,

Thank you for confirming that. Do you find this happens when opening all documents, or do some respect the current layout? Note that documents do have their own "initial view" settings, which can override this as well, you can check for that from the document properties (Ctrl+D): I hope this helps!

Hello Daniel,
Yes the issue happens when opening all documents.
The strangest, when the document is open without the properties pane visible, I noticed that:
1- when I set properties pane "ON", it become visible
2- If I close and then reopen the document, the properties pane stay visible.
3- If I do a new closure and then reopen the document, the properties pane is no more visible.
The test has been done on my Dell Workstation (Win10 x64) and on my ASUS laptop (Win 7 x64). The results is the same !!

Best regards

Gerard
FRANCE

Hello woinic!

My apologies, and thank you for the steps to reproduce this!
I have now reproduces this, and realized that somehow I had forgotten about this issue. I've actually reported this to the dev team not too long ago as another user brought the same issue to us. It seems that we have not made much progress on it yet, but it is being worked on.

All the best,

I'm experiencing this same issue, but with the Stamps palette. It used to work perfectly, now it sometimes doesn't get restored when I open a file. It's restored when I import settings.

Will the upcoming fix apply to the Stamps palette too?

Thanks.

Hello SFBAguy,
Hopefully, All panes will be covered in this fix, however at the moment we still do not have a timeline for the fix.

Kind regards,

I am experiencing the same problem with the initial view layout. I want to open a particular page with no thumbnails, only the page. I set the: File/Document properties/initial View/Navigation view to page only.
This should, as I understand from the thread, override all else, however. I can only get what I want if I go into:
Preferences/page display/default view => page only.
Is this how its meant to work or should the File/Document properties/initial View/Navigation view => Page Only override as mentioned ?

Hi bignose,

Thanks for the post - You'll need to enable this setting:

Hi Will,

Feel a bit sill I didn't see that one....sometimes it doesn't matter how hard one looks, one can easily miss what's staring one right in the face.

A bit like last time I stepped on the with my wife. Saw my girlfriend, but just looked right through her...... LOL

Anyway, appreciate you taking the time to clarify.

Regards
Mark

Hi,

The various problems described in the topic "Properties pane" do not seem to have been solved in the recent update "8.0 330.0".
Will these issues be resolved in the next update?
If yes, do you have any idea of the date for the next update?

Best regards,

Gerard
FRANCE

Hello Woinic,

Unfortunately this has not been brought into the current build, nor do we have a timeline available at this time. I cannot promise that it will be available in the next update either.
Apologies for the delays and any inconveniences they caused.

Kind regards,

This issue has gotten worse. It used to be that only the stamps palette window would open to some random size and position. Now the main window is doing the same, so I have to laboriously resize and reposition both windows when I open the app. I like the app, but this bug has become a real PITA and has reduced my appreciation of the app. It's affecting a bunch of us (most won't have posted here). How can fixing this bug be prioritized?

Thanks.

Hello SFBAguy,

I believe that you are thinking of something different from what this thread is focusing on. The Editor and its Panes will store the last used location when being closed normally. So if you have moved the window to an odd location, the application will place itself there again after closing and reopening. The same applies to each individual Pane within the application, and if you have moved the pane to another location, it will reopen in that location again next time it is opened.

Note that these locations are relative to Windows' current primary monitor, so if you frequently change which monitor is default, you may find that the locations do not perfectly match what you remember after one of these switches.

As for the issue currently being discussed in this thread, As of build 331.0, this now only occurs when the application itself is closed and reopened twice in a row, without any interaction with the panes in question. If leaving the Editor itself open, you can close an reopen as many documents as you like without it affecting some panes, such as the properties pane. Note that some panes are document specific (such as bookmarks and layout), and may close when all documents using them are closed; The main complaints in this thread however, Properties and Stamps, are not affected like this.

Kind regards,

Hi Daniel,

I would have responded sooner, but I didn't get notice of your reply.

Actually, what I'm experiencing is exactly what this thread is about. I just now tested opening a document, clicking on a stamp in the stamps palette, then closing the app. If I did all those steps, the editor and stamps palette would reopen every time. If I didn't click on a stamp, the stamps palette wouldn't reopen. So now I know of a workaround to get both windows to reopen; I just wish I didn't need to do it and that this bug would be fixed sooner rather than later.

Hello SFBAGuy.

As of build 331.0, this now only occurs when the application itself is closed and reopened twice in a row, without any interaction with the panes in question. This is then intended handling, as it is assumed that if you make it through an entire session without ever touching a pane, you do not need that pane permanently open, and leaving it open is simply wasting resources.

Kind regards,

Well, this is the problem with assumptions. :-S

I need the stamps palette when I proofread professionally, but I often look at PDFs that I'm not going to proofread, so of course I don't touch the stamps palette in those cases.

It's a mistake for a software vendor to assume it knows how its users want to use its software. This is a lesson Microsoft has been slow to learn, to the vast annoyance of its customers. Just let us decide when we don't need a pane—they're easy enough to close.

Another part of the problem here is that you don't reopen the pane in the same position and size it was when you decided to close it. So every time I have to reopen it, I have to yet again move it and resize it. Closing it on me wouldn't be as bad if you would reopen it the way I had it. Can you do that, at least?

Hello SFBAguy,

Window locations after closing should already be remembered, and in testing here, it seems that they indeed are.

As you seem to be having some issues with these functions, can I ask you to try resetting your settings (File > Manage settings > Reset settings) and then setup your panes as desired, and verify that their positions are remembered by closing and reopening them?

Regards,

Hmm, two steps forward, two steps back. I reset the settings. The stamps palette then seemed to reopen. It shifted itself a little from where I left it, but it seems consistent in reopening there. BTW, I use a set of custom stamps.

Then I clicked on a stamp, then the PDF, then I undid stamping the PDF, then I closed the app. When I reopened it, the stamps palette did not reopen. Clicking a stamp was supposed to make sure it reopened, wasn't it? When I reopened it manually, it was not in the same position or size it was.

Hello SFBAguy,

Indeed it should, and seems to be working on this end. Can you verify that "restore last used..." is enabled? It should be enabled by default: Other than that, as I am having trouble reproducing this here, Can I ask you to export your settings and share them with us? You can do that via File > Manage settings > Export settings.

Yes, "restore last used..." is enabled.

Exported setting attached.

Thanks.

Hello SFBAguy,

Thank you for the settings, I am unsure if it was the settings themselves that did it, or if I am doing something differently from before, however I see what you were talking about now, and after some discussion with the dev team, we have made some changes, the issues have been fixed, and as per your earlier suggestion, we will be making the panes open state and position persistent regardless of how many open/closes happen between uses.

This should all be available in the next build (332) of the Editor that we release.
I apologize for how long it took to come to an understanding of the issue there.

Kind regards,

That's terrific news, Daniel! Thank you for persisting. I look forward to the new version.

Two things:

The Tracker Update window also doesn't remember its position and size. Will you guys please fix that while you're at it?

About when do you expect the next Editor update to be released?

Thanks again!

Hello SFBAguy,
The Tracker updater window appears to remember its location on my PC, how can you reproduce this issue?

As for the next update, I unfortunately cannot provide any estimates at this point in time.
Kind regards,

Hi Daniel,

Well, of course it's not doing it now, but I know that in the past several days, the update window was appearing in different places on my screen and in different sizes. I'll see if I can get it to do it again and let you know if I can document the process.

Meantime, can you figure out why I never get notices of replies to this thread? The "Notify me when a reply is posted" box is checked.

Thanks.

It happened again. I rebooted my computer since yesterday and just now in Editor, I went to Help > Check for Updates, and the update app window is large and centered on my screen. Yesterday when I closed it, it was small and in the lower-right corner.

Hello SFBAguy,

Our web developers are looking into the cause of your email notification issues. They have advised me to check your spam folder in case it was being filtered there automatically in the meantime.

As for the location of the updater. This is stored in the registry, so if you have any registry clearners (CCleaner for example) you will need to ensure it does not affect our registry keys. Further than that, it is also recorded on a per-user basis, and located in: This means if you are logging into a different user account, it would be expected for the location and size of the window to change.

I hope this helps!

Hi Daniel,

My web host implements spam filtering, and it works very well. I wasn't able to find any emails from *tracker* (those are wildcards) in the incoming logs, spam filtered or not. Nonetheless, I've added a whitelist entry for *.tracker-software.com.

I don't use a registry cleaner, and I don't think I have any other software that would affect those registry keys. I checked the keys, loaded Updater, then moved and resized its window, closed it, exited it, then refreshed the Registry Editor window. The numbers updated to represent the new location and size. I've rebooted since then, and the numbers and window haven't changed yet, but they seem to eventually. I'll let you know when I see it happen again.

Any other ideas?

Thanks.

I invoked Update, and it moved and resized its window again. I looked at the MainWnd registry entries, and they looked like what they were when I had closed Update the last time. So it seems as though Update just didn't use those entries when it set up its window. I resized and moved the window again, and it updated the registry with new numbers. It now open in the same location, so it looks like an intermittent bug.

Hi SFBAguy,

well the Updater is it's own application and just closing the window wuith the X in the corner may not be enoufg. You should exit the Updater from the System Tray to truly close it and force writing settings to the registry. Without that the coordinates may still be in RAM.
Regardless, that is a nuance on the tests. We are still unable at this juncture to reproduce the issue with the Updater not remembering the location on screen. Intermittent issues are hard to nail down, but we will continue to look for a cause here.

Regards the Stamp palette only opening on one program restart, that is confirmed "fixed" for 8.0.332.0 slated for release August 26th.

I hope that helps.

Yes, in a previous post, I mentioned closing Updater, then exiting it, so I'm aware those are distinct steps. (A bit of a nuisance too—why would I want Updater to stay open, using up resources, when I know there aren't any updates?) I have to exit the app entirely, and maybe even reboot, for the old window coordinates not to be used.

Great, that's good to hear about the next version.

And I got emailed notice of your post, so that problem may also be fixed.

Thanks for continuing to try to figure out these issues. If you want me to use a one-off debug version that logs what it's doing or whatever, let me know.

Thanks SFBAguy,

we may ask you to use a debug version yet. You said the Updater Windows issue is intermittent,

I resized and moved the window again, and it updated the registry with new numbers. It now open in the same location, so it looks like an intermittent bug.

If you have any inspiration or revelations as to what might trigger it please do let us know. At the moment we are at a loss to reproduce it.

After months of waiting, yesterday I upgraded to 332.0 with high hopes, set up my panes, and was happy to see that they stayed in place through several cycles of opening and closing the app.

Until they didn't. The panes have changed their positions several times. And sometimes they do stay in place, and I don't know how to make them stick or not stick.

How do we proceed?

Hello SFBAGuy,

Thank you for the report, Unfortunately, unless we have a way to reproduce this, or someone else is able to replicate the issue, due to its "intermittent nature" and seemingly only affecting yourself, we must say there is likely something local to your device causing this.

While I cannot rule out the possibility that it could be internal to our application, all signs point to it being an external factor that is only present on your machine. If possible, do you have another machine or a colleague's where you could attempt to reproduce the issue?

Finally, if the issue does continue both on your machine, and another, please take a very close look at both for any mutual applications that have registry altering capabilities. This includes registry cleaners such as CCleaner, "advanced" security software such as Avast or Norton, even system services such as Windows Updates, as well as countless others.
If you can identify a pattern to the issues, perhaps the happen after a security scan for example? That information may help us to find or reproduce the issue.

Kind regards,

Hi Daniel,

Maybe we're getting somewhere. I found the relevant registry key (HKEY_CURRENT_USER\Software\Tracker Software\PDFXEditor\3.0\Settings\MainFrm\Rect) and set up Process Monitor to monitor accesses to that key.

My laptop has a 4K screen. A while back, because PDF-XChange Editor wasn't handling my high-DPI screen correctly, after right-clicking on its shortcut, I checked the box under Properties > Compatibility > "Change high DPI settings" > "Use this setting to fix scaling problems for this program instead of the one in Settings."

A couple days ago, with Process Monitor running, I kept opening, resizing, and closing Editor, and the window was restored correctly. Then I saw the i.top value set to 4,294,967,295‬ ($ffffffff). After I closed Editor and reopened it, sure enough, the window size and position had been reset, I figured because if the i.top value is larger than the i.bottom value, either Editor or Windows discards all window values and makes up new ones.

I unchecked the "Use this setting..." box and didn't seen the i.top or window sizing problem again over a day or so. I just rechecked the box and eventually saw the high i.top number again. I reopened Editor, but this time the window was restored correctly but the i.top registry key was deleted. I've reopened Editor and had to move the window for the key to be reinstated.

I've now unchecked the box again. In the last couple days, I've seen the problem only the one time I mentioned above. Because the problem is intermittent, I won't know for sure it's fixed for another few days, but it seems likely.

This has been a real head scratcher. As for remaining issues, either Windows or Editor came up with that bogus i.top value that may have caused the problem, and something deleted the i.top key.

It looks like it's not Windows. I still have the "Use this setting..." box unchecked, and the window resizing happened again.

I've attached a log of registry accesses made by Editor (I've never seen any other app change these keys). Note how on line 26, as I close Editor, i.right is set to 3833, which is correct. But when I reopen Editor, then close it again—without moving the window at all—on line 57, where it should write 3833 again, it instead writes 1916. And changes the other window coordinates too. When I opened the app again, the window had been resized. Maybe this only happens on high DPI screens, but it's definitely happening.

when i.Top (or i.Left) has 4,294,967,295‬ ($ffffffff) value or similar huge value it is absolutely ok as this number is treated by the Editor as a signed value, and actually represents relatively small negative value.
Also, when any of these values are absent, it just means that these values have value 0.
The problem must be somewhere else, and I must say we have never seen such a problem.
Can you please provide a screenshot of your Compatibility settings for the Editor, and also screenshot with your displays configuration?

Oh, okay.

I've attached the Editor's compatibility settings (I think these are all default settings) and some display settings. If you had different display settings in mind, let me know which.

Thanks for following through with this frustrating issue.

Thanks for the file. Will try to reproduce the issue.

Have you reproduced the issue? What are next steps?

Hello SFBAguy,

I spoke with Ivan a few minutes ago and he says that he can't actually reproduce the problem on his end, so we are going to ask another colleague in the dev team to take a look and see if they will manage to reproduce it.

Regards,
Stefan

Okay, thanks. Again, if you want me to run a debugging version or something, let me know.

Thank you for the offer, We will let you know if it comes to that.

I've waited another three weeks with no response from you.

As a workaround, I'm writing a batch file that overwrites registry entries to set window positions. I know the relevant registry keys that set window positions for local PDF files. What are the keys to set the window position for files opened from browsers, which seem to be different?

Hello SFBAguy,

Apologies for the delay, The developers needed to work on this were on vacation until recently and unable to offer much assistance. So far reproducing this has not been possible on our end, so we have not made much guaranteed progress attempting on reaching a resolution. There may be some improvement with the upcoming 334 release, but I cannot guarantee it will be fixed there. I am glad that you've found a temporary workaround for the issue, and hope that it wont be necessary for too much longer.

Regarding the registry keys, To my knowledge the application initiating the open operation should have no relevance on these positions, the only key values should be within our application folders, even when opening from browsers, the window location should be the same as when the Editor is opened manually.

Just to be certain here, is it possible that you have multiple instances of the application on your machine (perhaps the portable version) and have are opening the installed vs portable version separately with different applications? That is the only situation in which I could see the default window location changing, as the portable version does not use any registry entries.

Kind regards,

I see. My workaround only works with local files, which is less often what I use. This problem appears multiple times a day.

So what will have been changed in 334?

I don't think the browser is setting up the window either. But it looks like PDFXE is using a different set of stored coordinates or a different algorithm or something to set up its window depending on the source of the file it's opening. It does seem to keep opening the web-based files with the same coordinates as with other web-based files.

There isn't another copy of PDFXE on my system. I've verified the path to the app with a task manager tool, and regardless of the file's source, it's the same copy of the editor.

I've tried uninstalling the app and reinstalling, with no difference. With Microsoft Office, the uninstaller doesn't really uninstall the whole set of apps, and there are procedures online for a true uninstall that removes every bit of the apps. Does the PDFXE uninstaller truly remove every vestige of the app, or is there a more-thorough uninstall procedure?