Hyperion Entertainment Message Boards

I have an application where I need to rapidly close and reopen a window for a GUI chnage (bordred to borderless window in this case).

The window will be on a public screen but at the point of needing to close and reopen I only have the screen pointer, I don;t know what the screenname is (I might have fallan back to the workbench for example rather than opening on my original requested screen).

I need that pointer to stay valid whilst the window is brielfy close else some really nasty happens, so the obvious solution would be to lock it whilst closed but LockPubScreen() only takes a STRPTR to the name.

Is there a correct way to lock a screen when all you know is the pointer to the screen?

(and if that way was 68k compatable too that would really help! But not a deal breaker.).

Use IIntuition->GetScreenAttr() for OS4.x.

@broadblues
IIntuition->GetScreenAttr() is great for OS4 but doesn't exist in OS3. The only way I see to get the screen name in OS3 is to get the screen list with LockPubScreenList() and traverse the list comparing the psn_Screen pointers in the PubScreenNode structures to your screen pointer and copying the ln_Name (in psn_Node) from the matching node. I've never tried it but it seems to be a possibility.

EDIT: Based on the note about timeliness in the autodoc it might be best to search the list inside a Forbid()/Permit().

xenic wrote:@broadblues
IIntuition->GetScreenAttr() is great for OS4 but doesn't exist in OS3. The only way I see to get the screen name in OS3 is to get the screen list with LockPubScreenList() and traverse the list comparing the psn_Screen pointers in the PubScreenNode structures to your screen pointer and copying the ln_Name (in psn_Node) from the matching node. I've never tried it but it seems to be a possibility.

EDIT: Based on the note about timeliness in the autodoc it might be best to search the list inside a Forbid()/Permit().

Hmm that's possibilty thanks. Don''t think you'd need forbid /permit though, if the function lock's the list it's locked so nothing else can get at it, and I'd need to be just as quick inside a forbid /permit pair as I would holding the lock.

There are 2 things that might be easier than using the pubscreenlist:

• the screenname should be found in struct Screen.DefautTitle and/or Screen.Title
• open a empty dummy window to lock the screen while changing the other window

ZeroG wrote:There are 2 things that might be easier than using the pubscreenlist:

• the screenname should be found in struct Screen.DefautTitle and/or Screen.Title
• open a empty dummy window to lock the screen while changing the other window

Those are different names. Screen.Title is the name that's displayed in the screen dragbar if no windows are active on the screen. Screen. DefaultTitle is the name that appears in the screen dragbar if there is an active window that doesn't set a screen title. You can see how it works on the Workbench screen. If there are no program windows active, the Workbench dragbar has the the memory information (unless you changed it in Worbench prefs). If you open SYS:System/Find and make it the active window you will see the name "Workbench Screen" in the screen dragbar. If you open SYS:Utilities/USBInspector and make it the active window you will see "USB Inspector" in the screen dragbar because it sets a screen title. The Screen.name is the name you use to identify a screen for functions like LockPubScreen(). Some programs like Dopus4 sets the Screen.title, Screen.name and ARexx port to the same name. It can be confusing when you want to set a program to open on a pubscreen instead of Workbench.