a small extension of the MessageRequeter()

[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

[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

[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.

[TerryHough]

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.

[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:

Code: Select all

IF Warning(101) = 6 : END : Endif

Which (IMHO) is much simpler than the longer construct in your example.

[yashaa]

Which (IMHO) is much simpler than the longer construct in your example.

Simpler to write, harder to read

[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!

[SimpleMind]

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