In ID v17.3 I have a dialog that I need to close, then re-open exactly at the same spot after doing some work on the Document, i.e.
var oldDlg = new MyDialog(); oldDlg.show(); var oldLocation = oldDlg.win.frameLocation; //e.g. [100, 100]; // ... do some stuff to the Document ... var newDlg = new MyDialog(); newDlg.win.frameLocation = oldLocation; //tried doing this from onShow, but no difference newDlg.show(); //doesn't show at the same place, shows up at 2x old coordinates var newLocation = newDlg.win.frameLocation; //this is now e.g. [200, 200]!!!
In other words, the frameLocation that's reported after the show() is MULTIPLIED by the current internal UI scaling factor, 2x in this case. Sure enough, the multiplication factor changes depending on the UI Scaling preference, so UI Scaling has to be in effect. Yet, show() of the new dialog needs frameLocation in UN-multiplied units!
This smells like a bug. I can work around it by pre-adjusting oldLocation by multiplying by (oldDlg.win.preferredSize / oldDlg.win.size), but what if Adobe come back and fix this someday and break my script in the process? (BTW Adobe, the discrepancy of preferredSize vs size is also nonsensical.)
So, is this a feature or a bug? If so, in which versions?
Does anybody have a safer idea for a workaround?
This is a CC bug:
In short, the Window metrics (location, size, etc) are set in SUI coordinates but they return screen coordinates:
Thanks so much for that, Marc!
From your post I see we're both doing the same ugly workaround of scaling the location by the ratio of expected vs. SUI-reported size. This leaves me concerned that Adobe will fix the location-scaling problem in some future version of ID, effectively turning the workaround into a bug in my code!
You're much more plugged-in with Adobe than I am, and you're doing it; should I understand that you have reason to believe that Adobe will leave this "feature" as-is, or are you just planning to add version-dependent code if & when they change it?
(…) This leaves me concerned that Adobe will fix the location-scaling problem in some future version of ID, effectively turning the workaround into a bug in my code! (…)