Maybe a new entry in the "Software Support" forum would be possible?
@amigakit
AmiPDF 1.37 (20.9.2016)
Bug:
- When starting a new instance of AmiPDF the snapshotted window position that has been saved before (from within AmiPDF) IS used.
- When starting AmiPDF with a PDF file as option (i.e. "AmiPDF path/pdf-file") regaardless being in a shell, using a browsers MIME setting or a shortcut in AmiDock, the window snapshot information is NOT used, instead the AmiPDF window is blown up to the max eating away massive gfx mem
Please fix it
...and no, i won't create yet another account at yet another bug tracker, thank you
- When starting a new instance of AmiPDF the snapshotted window position that has been saved before (from within AmiPDF) IS used.
- When starting AmiPDF with a PDF file as option (i.e. "AmiPDF path/pdf-file") regaardless being in a shell, using a browsers MIME setting or a shortcut in AmiDock, the window snapshot information is NOT used, instead the AmiPDF window is blown up to the max eating away massive gfx mem
Works fine here.
Are you sure the same AmiPDF is being run in each case?
Quote:
Please fix it
...and no, i won't create yet another account at yet another bug tracker, thank you
Aw go on,please, you know you wan't to really, you'd be really welcome honest,
I was able to reproduce Raziels' snapshot issue and I think it's a Reaction issue (not an AmiPDF issue) which may be a feature; not a bug. Here are the results of some testing:
When AmiPDF is started from it's icon, snapshot saves the window position here: ENVARC:Sys/WindowData/AmiPDF/AmiPDF.xml
When AmiPDF is started from a shell, snapshot saves the window position here: ENVARC:Sys/WindowData/Shell Process/AmiPDF.xml
In other words, the location where the window position is stored depends on how the program is started. I tested a number of other programs that have the "snapshot" feature and they all save the position in a different location depending on how they were started.
I did find one potential problem snapshot problem when USBInspector is sharted from a shell. The name of the window position file is "MAIN_Window.xml". It seems to me like the filename should contain the name of the program to avoid conflicts with other program snapshot files,
EDIT: It might be smart for programmers to test snapshot from shell and icon start to be sure the snapshot filenames are correct.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@Raziel I think your snapshot issue is due to a Reaction feature and isn't a bug. Refer to my post to broadblues. You'll need to start AmiPDF from it's icon and snapshot the window; then start it from a shell and snapshot it again.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Time Prefs from the Enchancer seems to be stuck on GMT.
My time sever is ntp1.vodafone.co.nz port 123.
Everytime I boot up, it's 12 hours behind. I have "update at boot time" checked, but I have to manually open Time Prefs and click "Get time now" to get onto NZST.
Also, when I tick "Automatically adjust clock for Daylight Saving Time", it seems to be defaulting to some other country's settings (UK?), even though Locale.prefs knows my country's DST dates.
Hmm, good spot, I have both AmiPDF/AmiPDF.xml and ShellProcess/AmiPDF.xml and they are identical. Hence me not seeing any difference in behaviour.
I'm not convinced this is a feature, more of an emergent behaviour, I'll raise a BZ tomorrow, when I'm more awake.
The names of the windows are simply created from the UniqueID passed to the window class, the developer should have to care about anything else in something as high level as window.class The uniqueness of the names is significantly eroded in the ShellProcess case.
I don't have any "Shell Process" in ENVARC:sys/WindowData, so i guess i never bothered to snapshot anything from there.
Thank you also for the workaround, i'll wait for a proper fix, but will use your idea if it takes too long and the bahaviour is starting to get on my nerves
Thank you also for the workaround, i'll wait for a proper fix, but will use your idea if it takes too long and the bahaviour is starting to get on my nerves
It's yet to be determined if it's window.class bug or intended behaviour so Iwouldn't "wait for fix" but just snapshot both variants to your prefered location. A one off action.
Assuming you don't try and be 'clever' and take advantage of the two types of snapshot to have different settings when started from shell, when the fix is delievered if fiexed it be, you will never even notice.
But i don't think it's a "feature" to have the same program opened from different environments behave differently, that's just too confusing.
If there was was a shell "Prefs" that took care of the list of programs that behave differently and *shows* that accordingly it would be another matter. (Maybe even with the possibility to change those settings from the Prefs)
But doing that in the "hidden" way it is done now is confusing...thus me reporting it as bug...
Exchanger doesn't have an "About" tab in it's info window, i miss that because one can easily copy the programs information for bug reporting.
Second:
I can make Exchanger fall over
Steps to reproduce:
1) Open Sys:Utilities/Commodities 2) Start Exchanger -> all is fine 3) Start ScreenBlankerEngine from the same directory -> still fine 4) Double Click on ScreenBlankerEngine once more (it does matter if the ScreenBlankerEngine was in the list before, because it will fall over as soon as ScreenBlankerEngine gets *removed* from Exchanger's list)
From now on Exchanger will show in it's info part "No programs in list." for every program in the list -> Bug
As long as one doesn't close Exchanger (from it's menu, that is, it's NOT enough to simply close it's window, but to completely kill Exchanger with Project/Quit) and start it again it will stay this way.
It may also happen with other programs, i didn't bother to test.
I'm still getting the problem with Multiviewer where it freezes up the entire system randomly when opening text files (all other datatypes are OK). However it never does it consistently enough for me to be able to get a serial debug log. Consequently, I was getting so fed up of rebooting and having to re-open everything that I went back to Multiview.
It would be great if this could be fixed (although I suspect it depends on me being able to get a crashlog, which doesn't look likely to happen any time soon)
Although the Dock features an AREXX port (which first instance is always called XDOCK.1) it is not possible to open a second instance (XDOCK.2).
Actually nothing at all happens when starting X-Dock a second time.
With it's limitations right now i do need to open at least two instances of the program (better would be indefinitely, though) to be able to completely switch from AmiDock (I have a few neat tricks in AmiDock -honestly stolen from Mason's great Push4Dock package).
Though i have yet to test (when available) if two X-Docks on top of each other will behave the way i like it to be.
I'm still getting the problem with Multiviewer where it freezes up the entire system randomly when opening text files (all other datatypes are OK). However it never does it consistently enough for me
I too get this problem, and it's really difficult to reproduce (seems random).
Quote:
Consequently, I was getting so fed up of rebooting and having to re-open everything that I went back to Multiview.
For me on my x5k problem with Multivewer start right after i installing it and trying to open first single txt. It is always reproducable for me, and, sadly to say i am the same swith to Multiview :(
As i was able to reproduce it all so easy i wrote to Andy about, to offer help with crashlogs and stuff, but, Andy says crashlogs there didn't help, as problem start to happens before actual crash happens, and its hard to track it down. I also offer help with usuall "debug printf" , but Andy probably busy with all other stuff , and think that it happens not so offten.
@Andy As you see everyone have that problem, so , if you want and as i can reproduce it 100% all the time, i can help to track it down and give you any info you need :)
"Though i have yet to test (when available) if two X-Docks on top of each other will behave the way i like it to be."
You can have many XDock opened by simply starting once X-Dock binary.
Simply, use RMB to "Create a new dock". It will open an empty dock and create a xml file for it. Now each time that you start x-dock, xml files will be scanned and docks started (each with his own arexx port).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
