For my weekly how do I do something.
Is there a ASL like requester for a color requester? I have found Font/Screen/File etc in ASL library but nothing that looks like color?
Any suggestions?
Regards
Doug
Mon, 2018-03-19 01:06
#1
Color Requester
There is no ASL color requester, but there is a getcolor.gadget
@broadblues - Thanks after I posted I did notice this but cant quite figure out how to make it work for use case. I am trying to fulfill a function for the driver for the GUI library.
This is the prototype I must fulfill.
The gadget requires a window struct and I assume I can instantiate the gadget without actually putting it on a window? Or can I put it on invisible window? For windows/linux/osx there is API to get activewindow and I can pass that to a requester. I know I can lock Intuition and enumerate the screen and enumerate to the active window but my understanding is I cant really safely use the pointer after unlock.
Thanks I'll see what I can come up with.
Doug
DStastny
No it doesn't. It does however require a screen pointer. If you application doesn't have screen of it's own use LockPubScreen(NULL) to get the pointer to the default pubscreen (usually but not always workbench).
Normally you would use this gadget in a GUI , listen for click on it, and then invoke the GOLOR_REQUEST, but you can create a standalone object and just invoke the GCOLOR_REQUEST at will. The window pointer in that request is for the window to make busy, so no window, just pass NULL.
You culd but I don't thnk you need to.
No there is no need to do this, if you have window, you know all you need to know about it, if not, then DONOT EVER EVER EVER mess with another appliactions window pointers, especially not for opening a requester.
@Broadblues thanks for your insights and feedback. The challenge of trying to map implement a "cross-platform" API to Amiga is challenging as it gets. I appreciate your feedback and experience as the google machine only goes so far hunting around Amiga documentation.
Regards
Doug
DStastny
@Broadblues - I really hope my questions are not bothersome...
So I got a simple program working. But I must admit the documentation is very conflicting. The autodoc says the screen is required but the header says it is not. I did find it does require a window and works fine with out the screen. I assume it gets the screen from the window structure if you don't set the screen? Now for when you invoke LockPubScreen again the documentation is a bit fuzzy. Should I lock my window to a Pub screen as long as my application is alive or just if I need to access the screen structure? I saw one sample says only need to keep lock until I create the window. Bit confused on all this and help or guidance is appreciated.
Thanks for help
Doug
DStastny
Ofcourse not, that's what the forum is for.
The header days it defaults to None, that's not the same as saying it's not required.
It may well do. I'm sure I had used one of the get#?.gadgets without a window, perhaps I was misremebering.
It's not fuzzy you are squinting at it too hard :-)
You don't lock the window to anything.
LockPubScreen() locks a screen so that it cannot be closed, and returns the screen pointer. If the screen is containined in the public screens database, it can also open the screen in the first place (this is an AmigaOS 4 specific feature).
The Screen pointer is only valid whilst the screen is open, and likely invalid if the screen closes and reopens for some reason. (Common case might be a prefs change).
Once you have opened a window on the screen it cannot be closed, so you may release the lock.
Because third party events (that prefs change) might want to close and reopen the screen, you should keep thwe lock for as brief a time as required, keeping in mind that the pointer is only valid if the screen is guaranteed to be open. ie locked or window open.
With the above in mind it's not uncommon to UnlockPubSCreen() just after opening your window on it.
It's not a one size fits all situaion though, so that's why examples and doc s may seam to contradict.
A window once openned, does not require the screen to remain locked as it effectively locks the screen itself.
@Broadblues - Thank you sir for all your assistance. I am sure more questions will be coming so your patience and detailed explanations are appreciated.
Regard
Doug
DStastny