Page 1 of 1
a small extension of the MessageRequeter()
Posted: Fri Jun 24, 2005 8:31 pm
by PB&J Lover
Here is a procedure I use the simplify my MessageBoxes. It uses more flags than are listed in the help files (the commented ones don't work in PB).
Code: Select all
Procedure.b mb(cap.s,msg.s,flag.b,icon.b)
Select flag
Case 1 : flag = #MB_OKCANCEL
Case 2 : flag = #MB_ABORTRETRYIGNORE
Case 3 : flag = #MB_YESNOCANCEL
Case 4 : flag = #MB_YESNO
; Case 5 : flag = #MB_RETRYCANCEL
; Case 6 : flag = #MB_CANCELTRYCONTINUE
Default : flag = #MB_OK
EndSelect
Select icon
Case 1 : icon = #MB_ICONEXCLAMATION
Case 2 : icon = #MB_ICONQUESTION
Case 3 : icon = #MB_ICONSTOP
Default : icon = #MB_ICONINFORMATION
EndSelect
ProcedureReturn MessageRequester(cap,msg+" ",flag|icon)
EndProcedure
So you'd use it like this:
Result = mb("Caption","Message",0,0)
A good way to manage Warning messages is a Select/Case procedure like this:
Code: Select all
Procedure.l Warning(n.b)
typ.b = 0 : icon.b = 0
Select n
Case 101
cap$ = "- Warning! -" : typ = 4 : icon = 1
Msg$ = "Do you want to QUIT without saving? "
Case 102
cap$ = "- Sorry! -" : typ = 0 : icon = 3
Msg$ = "The file could not be opened! "
EndSelect
ProcedureReturn mb(cap$,Msg$,typ,icon)
EndProcedure
So in your code you can have:
mbResult = Warning(101) or
IF Warning(101) = 6 : END etc.
Hope this helps someone
Posted: Fri Jun 24, 2005 9:07 pm
by utopiomania
Thanks for the tip
, but my first thought was isn't this a bit upside down? Passing 0 instead of
#PB_MessageRequester_OK isn't too self documenting is it
Posted: Fri Jun 24, 2005 9:14 pm
by PB&J Lover
That's true, but then I just put this chart in my code or print it out. It saves room in the long run and makes the Warning procedure simpler too.
; - ******* Message Box mb() Function Parameters ********
; TYP: 0 = OK (default)
; 1 = OK CANCEL
; 2 = ABORT RETRY IGNORE
; 3 = YES NO CANCEL
; 4 = YES NO
; 5 = RETRY CANCEL
; 6 = CANCEL TRY CONTINUE
;
; ICON: 0 = Info (default) a small "i" in a bubble.
; 1 = Exclamation (in a caution triangle).
; 2 = Question Mark (in bubble).
; 3 = STOP (with X in red circle).
It works for me.
Re: a small extension of the MessageRequeter()
Posted: Mon Jun 27, 2005 2:56 pm
by TerryHough
PB&J Lover wrote:So in your code you can have: mbResult = Warning(101) or IF Warning(101) = 6 : END etc.
Did you overlook this construct?
Result = MessageRequester("Warning", "Do you want to QUIT without saving? ", #MB_OKCANCEL | #MB_ICONEXCLAMATION)
AFAIK, all of the "message box" #MB_ICON???? constants
are supported in PB. So I just use them this way since they are more
readable.
Re: a small extension of the MessageRequeter()
Posted: Thu Jul 07, 2005 2:26 pm
by PB&J Lover
Did you overlook this construct?
Result = MessageRequester("Warning", "Do you want to QUIT without saving? ", #MB_OKCANCEL | #MB_ICONEXCLAMATION)
No I didn't overlook this. What this system allows me to do is shorten that construct for all the Warnings or Messages I want to put in my program. I don't repeat the long constants like: "#MB_ICONEXCLAMATION" constantly, I have it only once in my Warning() procedure. This allows this construct:
Which (IMHO) is much simpler than the longer construct in your example.
Re: a small extension of the MessageRequeter()
Posted: Thu Jul 07, 2005 5:10 pm
by yashaa
PB&J Lover wrote:
Which (IMHO) is much simpler than the longer construct in your example.
Simpler to write, harder to read
Posted: Thu Jul 07, 2005 5:36 pm
by PB&J Lover
I must disagree here. I've already said I include a documented chart as a header to the Warning() procedure. All the Warnings are there grouped together and code is not duplicated everywhere I need the same warning/message (that's the way you
should be writing your programs).
This allows simple, clean, constructs like this:
Code: Select all
Case Gadget_DDM_Main_Cancel
If dirty <> #True : Gosub Cancel : End
Else
If Warning(105) = 6 : Gosub Cancel : End : EndIf
EndIf
You have to understand that Warning(105) might be used 2 or 3 times in the same section of code depending on the logical flow and perhaps many more times in the whole program. Duplicating long lines of code is sloppy programming.
It bloats your code and doesn't allow for global changes.
If I want to change the text of Warning(105) what do I do? In my system you simply change one line in the Warning() procedure and they all change. In your "easier" system you'd have to go hunting for them.
Also, if I want to use the same Warnings in a new program I just include the procedure as a file or copy it in and there you go. I have them all.
What I am suggesting is nothing new and anyone who's studied computer science will recognize the method and the reasons behind it. Here's to tighter code!
Posted: Wed Aug 24, 2005 4:08 pm
by SimpleMind
PB&J Lover wrote:I must disagree here. I've already said I include a documented chart as a header to the Warning() procedure. All the Warnings are there grouped together and code is not duplicated everywhere I need the same warning/message (that's the way you
should be writing your programs).
[...]
You have to understand that Warning(105) might be used 2 or 3 times in the same section of code depending on the logical flow and perhaps many more times in the whole program. Duplicating long lines of code is sloppy programming.
It bloats your code and doesn't allow for global changes.
If I want to change the text of Warning(105) what do I do? In my system you simply change one line in the Warning() procedure and they all change. In your "easier" system you'd have to go hunting for them.
Also, if I want to use the same Warnings in a new program I just include the procedure as a file or copy it in and there you go. I have them all.
What I am suggesting is nothing new and anyone who's studied computer science will recognize the method and the reasons behind it. Here's to tighter code!
I agree PB&J Lover. What you do is nice referenced here.:
http://www.duckware.com/bugfreec/chapter6.html#thekey