1. ClipViewer is less than useful if you use multiple screens because it always opens on WorkBench and doesn't bring the WorkBench screen to the front. I suggested that they add a FRONTSCREEN tooltype so that ClipViewer will open on the screen where you are currently editing. I also suggested a PUBSCREEN option and to have it bring the screen that it opens on to the front .
BTW there is no reason to think that the Frontscreen is the one that is being worked on, it frequently isn't when screen dragging is in use.
BTW there is no reason to think that the Frontscreen is the one that is being worked on, it frequently isn't when screen dragging is in use.
If that concerns you then get the IntuitionBase "ActiveScreen" pointer and compare it to the FirstScreen pointer to confirm that the front screen is the active screen. There are several possibilities:
1. Get the FirstScreen and the ActiveScreeen and open the window on the FirstScreen if they are the same.
2. Get the FirstScreen and open the window on that screen.
3. Get the ActiveScreen and open the Window on that screen.
If any of the above fails or proves inconclusive then just open the window without specifying a screen (so it opens on the default public screen) and bring that screen to the front.
However, I'm fairly sure that most users would be satisfied if there was a FRONTSCREEN tooltype to have ClipViewer open on the front screen. I think they will realize that it's their fault if they are dragging screens to have several screens visible and then open Clipviewer.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
O.K. However, it seems unlikely that other programmers will want to use the Enhancer libs, devs, classes etc. if there's no guarantee every user will have purchased Enhancer and have them installed.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
That possibility is why I made it a guess FYI I've never installed any themes and don't have a gadget background texture. It's possible that the gadget background texture is not present after a system install.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I wasn't aware of the SA_PubName tag but it doesn't change much since you are not allowed to call intuition or other high level functions while holding a LockIBase() lock and if you unlock you can't be sure that the screen pointer will stay valid for your call to GetScreenAttr().
OTOH the solution I suggested only uses the FirstScreen pointer for comparison so the worst thing that could happen is that you can't find the screen in the pubscreen list because it was closed before the call to LockPubScreenList().
I wasn't aware of the SA_PubName tag but it doesn't change much since you are not allowed to call intuition or other high level functions while holding a LockIBase() lock and if you unlock you can't be sure that the screen pointer will stay valid for your call to GetScreenAttr().
OTOH the solution I suggested only uses the FirstScreen pointer for comparison so the worst thing that could happen is that you can't find the screen in the pubscreen list because it was closed before the call to LockPubScreenList().
Since GetScreenAttr() would need to lock the list to find the screen you provided as an argument, I doubt if there would be much time difference for either method and if the screen is closed before GetScreenAttr() can lock the list it should return an error. Either method could theoretically fail to get the name and lock the public screen before the screen closes. However, I think it's unlikely that user could click an icon or menu to open a program and close the screen before the program locks the screen. 800+ MHZ is a lot faster than any human reaction but I suppose it could happen. The worse result would be that the program would need to open on the default public screen (as it does now).
I just noticed that LockScreenList() returns a pointer to the first screen so it might be quicker to do something like: "if (screen = LockScreenList()) UnlockScreenList" than locking IntuitionBase.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Since GetScreenAttr() would need to lock the list to find the screen you provided as an argument
GetScreenAttr() does not need to do anything to find the screen you passed to it, as you just passed the pointer to the screen to it. Pass a stale pointer and bad things will happen.....
Use WBenchToFront() everytime and WBenchToBack() if workbench wasn't the frontmost screen when the hotkey is used.
If you read my original post you will see that I suggested that the screen that ClipViewer opens on be brought to the front. Since the default public screen can be changed by utilities like "setdefpubscreen" at OS4Depot or similar utilities at Aminet, you can't always assume that programs will open on Workbench. Also, I don't know if WBenchToFront() does anything if you are using a Workbench replacement application like Dopus5.
However, I think you missed the point in my request that a 'FRONTSCREEN' (or similarly named) TOOLTYPE be added to Clipviewer. The point is that with ClipViewer you can select a previous cllip to paste into an application and that it's more desirable to have ClipViewer open on the same screen as your current application to select the clip and paste it into the app. As it stands now, it you are working on a screen other than Workbench then Clipviewer quietly opens on the Workbench screen leaving you wondering if you typed the wrong popup keystrokes. Once you realize it's always opening on Workbench then you need to open it, change to the Workbench screen to use it and return to the screen you current application is on.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
GetScreenAttr() does not need to do anything to find the screen you passed to it, as you just passed the pointer to the screen to it. Pass a stale pointer and bad things will happen.....
You're right. If GetScreenAttr() doesn't check the screen pointer validity with the screen list it would probably be Grim Reaper time. salass00's method would be safer and the right method to use. I've used GetScreenAttr() in several personal-use programs to open them on the front screen and never had a crash but I suppose that's just luck. I'm going to recompile them with salass00's method.
It would probably be a good idea to make an addition to the GetScreenAttr() autodocs stating that the screen should be locked before calling GetScreenAttr() so that people like me don't make false assumptions about how it works.
EDIT: I did some more testing and it appears that ClipViewer specifically opens on the Workbench screen instead of the default public screen. I have a personal-use program (defpub) that I use to test if programs open on the default public screen. As I pointed out to Severin, there are utilities available that can change the default public screen and programs like Dopus5 that can replace Workbench. In keeping with the way that other the OS4 system programs work, I think ClipViewer should be opening on the default public screen.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
It would probably be a good idea to make an addition to the GetScreenAttr() autodocs stating that the screen should be locked before calling GetScreenAttr() so that people like me don't make false assumptions about how it works.
It doesn't need to be locked, the pointer needs to be valid (Locking *is* a way of ensureing that, other ways are owning the screen, or already having a window open on it).
It does not say it will validate your pointer, and in general GetAttrs styles functions do not, so why would you assume it would?
ClipViewer is not my project, It's written by Massimo, but I think Matthew mentioned in the fisrt thrad that you brought all this up (on aw.net) that your points had been addressed in the next version...
ClipViewer is not my project, It's written by Massimo, but I think Matthew mentioned in the fisrt thrad that you brought all this up (on aw.net) that your points had been addressed in the next version...
Sorry about repeating the report but at my age I'm lucky if I can remember what I did yesterday.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
The next version of ClipViewer has had a lot of changes under the hood. You may be interested to hear of these specifically:
Quote:
Added PUBSCREEN/K command line option and PUBSCREEN=<name> tool type for specifying the public screen the ClipViewer window should open on when it is invoked through the hotkey combination. As a special case, PUBSCREEN=FRONTMOST makes the ClipViewer window always open on the frontmost screen, as long as it is a public screen.
- Added CVA_PubScreenName tag for StartClipViewerA(), as an alternative to passing the target public screen's address directly.
- When a ClipViewer client window opens, the public screen it appears on is now brought to the front.
@amigakit Great news! I'd like to point out that the intent of my original post in this topic was to add some observations about programs in the current Enhancer package to the observations posted by ChrisH. When Trixie posted that getting the front screen was a 'hack' and I responded, the topic evolved into a big discussion that turns out to be almost meaningless given that the ClipViewer author has updated the program.
Thanks for the info.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
If that concerns you then get the IntuitionBase "ActiveScreen" pointer and compare it to the FirstScreen pointer to confirm that the front screen is the active screen. There are several possibilities:
1. Get the FirstScreen and the ActiveScreeen and open the window on the FirstScreen if they are the same.
2. Get the FirstScreen and open the window on that screen.
3. Get the ActiveScreen and open the Window on that screen.
If any of the above fails or proves inconclusive then just open the window without specifying a screen (so it opens on the default public screen) and bring that screen to the front.
Thanks for the info. If I ever find the time, I might try patching LockPubScreen(NULL) to return the front-most (or active) screen. (If it is public - if not then I would just return the real default public screen.)
I'm hoping that this might also fix URLopen's choose-a-browser requester always opening on the Workbench screen...
When Trixie posted that getting the front screen was a 'hack' [...]
And it indeed is a hack! When something entails locking the IntuitionBase, walking the list of open screens, and checking whether the first screen is actually a pubscreen, we can't seriously speak of an Intuition-supported way to open your program on the frontmost screen. Regardless of what the autodoc says - heck, it was written 20 years ago, when you could get away with all sorts of tricks.
What we need is LockPubScreen() supporting a FRONTMOST parameter. Let the system do the dirty work, not the programmer.
It would probably be useful for LockPubScreen to have some sort of PUBSCREEN_FRONTMOST option (might need to be a new function for compatibility reasons).
Since LockPubScreen() expects a string that may not be possible. It would be convenient to have a new function such as "GetFrontScreen()".
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
FYI I've never installed any themes and don't have a gadget background texture. It's possible that the gadget background texture is not present after a system install. 
