|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue May 12, 2009 9:30 am Post subject: Inhibit subsequent callback |
|
|
I've got one of those "double callbacks" where I have used '+', as in:
Code: | '+', callback1, callback2 |
As a result of something that happens in callback1, I would like to skip callback 2.
If callback2 is something I have written, I can just set a variable (in callback1) that callback2 looks at before taking any action. However, when callback2 is a "standard callback", such as 'FILE_OPENW', I can't do that.
Is there a return code in the "reserved list" that will do what I want?
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue May 12, 2009 10:10 am Post subject: |
|
|
I have had a look at the documentation and the ClearWin+ code but at the moment I cannot see a way to do this. |
|
Back to top |
|
|
acw
Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon
|
Posted: Tue May 12, 2009 10:19 am Post subject: |
|
|
This isn't a particularly pretty suggestion, but you could define a user message (eg. WM_MYMESSAGE = WM_USER+1001), and execute callback2 via a %mg rather than the double, then use the win32 SendMessage(WM_MYMESSAGE) or PostMessage at the end of callback1 to persuade callback2 to execute. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue May 12, 2009 10:44 am Post subject: |
|
|
Thanks for both of the replies and acw's suggestions. My application is a "single document" program, and I just discovered that File|Open didn't give a Save option before the new file was read. The callbacks to File|Open were:
Code: | 'File_OpenR', filename, Open_FUNCTION, |
I initially coded the Save option in the Open_FUNCTION "follow on" to 'FILE_OPENR', but found it required mental gymnastics beyond my elderly brain to cope with two files in the "wrong order" as it required giving the new file name, then being asked if I wanted to save the old data - a sequence that is susceptible to muddling up which is the file to open, and which to save - although it worked fine with File|New, where one of the file names is "untitled" (and it doesn't exist yet).
It occured to me that prefixing this callback with another as in:
Code: | '+', Saver_FN, 'File_OpenR', filename, Open_FUNCTION, |
would be an easy route, as in Saver_FN I could have a Save option which would put the old data to bed before going on to 'FILE_OPENR', a Discard option that wouldn't save first, but also required was a Cancel option that is "don't save OR Open a new file" - for which I needed to inhibit the 'FILE_OPENR'.
The idea of being able to inhibit subsequent callbacks is a useful one, especially where 'EXIT' or 'CONFIRM_EXIT' are concerned, and I suggest to Paul that this is something worthy of consideration for the future.
As it is, the route I will foillow is to abandon 'FILE_OPENR' and do a get_filtered_file@ instead.
Of course the initial problem does not exist if the application has an MDI, since neither New nor Open imply closing the existing workspace.
Eddie |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|