Announcement

Collapse
No announcement yet.

PBForms BEGIN/END DIALOG feature

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PBForms BEGIN/END DIALOG feature

    I just noticed that when editing a PBForms app that the statement which I had inserted after DIALOG NEW was discarded. In fact this was a macro including a setprop statement, the purpose of which was to pass a value from the dialog proc to the callback proc, which the callback could pick up in its WM_INITDIALOG handler.

    Is there any setting or strategy by which I can talk PBForms into not doing this.

    If not, from a design point of view, would it not be better to alllow "user code" to be inserted between the DIALOG NEW and CONTROL ADD statements? It's not like code between the CONTROL ADD statements which might get lost in shuffling the z-order.
    Last edited by Chris Holbrook; 19 Mar 2008, 06:27 AM. Reason: replaced "recompiling" on line 1 with "editing"

  • #2
    Keep your alterations outside the #PBFORMS statements and pbforms won't touch them...
    Adam Drake
    PowerBASIC

    Comment


    • #3
      Originally posted by Adam J. Drake View Post
      Keep your alterations outside the #PBFORMS statements and pbforms won't touch them...
      you don't say... the point is, it is sometimes necessary to get between the DIALOG NEW and the CONTROL ADD statements, which PBFORMS groups together in one block.

      Comment


      • #4
        Sorry, running on very little sleep at the moment - misread the original post. At the moment, it simply doesn't support it (as you have found out).

        That being said, what type of situation have you encountered that requires code alterations in between DIALOG NEW and CONTROL ADD? I haven't yet encountered a situation I couldn't workaround and keep it outside the blocks...
        Adam Drake
        PowerBASIC

        Comment


        • #5
          Easy fix,
          1. Create your dialog and controls in PB Forms
          2. Copy/Paste the code to PbWin
          3. Strip out the PBForms codes
          4. Add your code where you want it
          5. Compile
          6. Run

          Engineer's Motto: If it aint broke take it apart and fix it

          "If at 1st you don't succeed... call it version 1.0"

          "Half of Programming is coding"....."The other 90% is DEBUGGING"

          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

          Comment


          • #6
            Originally posted by Cliff Nichols View Post
            Easy fix...
            I would call that a workaround, not a fix! In fact there is no problem compiling the code with both the #PBFORMS directives and my nonconforming line of code. It is in editing that the line is lost, not compiling.

            It appears to me that PBForms assumes that there is no need to put code between the DIALOG NEW and the CONTROL ADD, and in assuming that it assumes too much.

            Comment


            • #7
              Simply put your code outside of the #PBFORMS block statements and it will not be touched.
              Sincerely,

              Steve Rossell
              PowerBASIC Staff

              Comment


              • #8
                Originally posted by Adam J. Drake View Post
                what type of situation have you encountered that requires code alterations in between DIALOG NEW and CONTROL ADD?
                setting a property of the dialog which is read by the control's WM_INITDIALOG.

                Comment


                • #9
                  Originally posted by Steve Rossell View Post
                  Simply put your code outside of the #PBFORMS block statements and it will not be touched.
                  There we go, speaking the same language and not communicating, again.

                  1. I know that PBForms won't touch code outside the #PBFORMS directives, because the documentation tells me so.

                  2. I take your comment to mean "there is no way you can change this behaviour", and that's OK too.

                  3. It seems pretty reasonable to me that someone might want to do something inside the dialog proc after creating the dialog and before the control's WM_INITDIALOG message is received. I've given you an instance of this. There are workarounds, both in procedure (re-edit the code after making design changes in PBForms, etc), and in technique ( use a global or send a WM_USER + message instead of using a property). But in either case, the design of PBForms is constraining either what the developer wants to do, or putting obstacles in his way in doing it.

                  4. It's not the end of the world, but I thought it worth bringing to the attention of my peers and the PBForms designer.

                  Comment


                  • #10
                    Chris, without knowing the details of your program, could you put off adding your controls until WM_INITDIALOG? I do that sometimes, anyway.

                    Edit: Sorry, I see how stupid this idea is... I don't use PBForms and I keep forgetting that it sets the rules for adding controls.
                    Last edited by Charles Dietz; 19 Mar 2008, 11:08 AM.

                    Comment


                    • #11
                      Chris,
                      Doesn't this work for you?
                      Code:
                       
                      #PBFORMS BEGIN DIALOG %IDD_DIALOG1->->
                      ...
                      #PBFORMS END DIALOG
                       
                       SetProp hDlg, "testProp", 1234
                       
                        DIALOG SHOW ...
                      Rgds, Dave

                      Comment


                      • #12
                        Originally posted by Dave Biggs View Post
                        Doesn't this work for you?
                        Yes it does, and thank you Dave.

                        Comment


                        • #13
                          Originally posted by Charles Dietz View Post
                          could you put off adding your controls until WM_INITDIALOG?
                          Charles, the problem is to get info passed in to the callback proc, which takes no parameters. I don't want to use globals or a custom message, so using a property to pass a pointer to stuff seemed a good plan. Moving the ADD CONTROL statements to the callback works, but PBForms can't see them so it just shows you a blank dialog in the edit session.

                          In fact as I write Dave Biggs has identified the solution, and I was wrong about when WM_INITDIALOG is sent, I think WM_CREATE gets send right after the control is created but you don't see it until the ShowDialog starts messages beging sent to the callback proc, so I assume the WM_DIALOG is a DDT message. Anyway I was wrong about that and now its fixed.

                          I also hereby unreservedly withdraw my remarks re. design of PBForms before Mr Zales' lawyers come knocking.

                          Comment


                          • #14
                            Yes, I also thought this to be repaired - I think about two years ago.
                            I wonder why nothing changed in the mean time.
                            Norbert Doerre

                            Comment


                            • #15
                              When I am working on any program that I used PBForms to design the layout on, which is almost all programs I work on lately, I keep the file in both PBForms and PB. By keeping the PBForms window open, but without focus, if I edit a line, anything, anywhere in the PB IDE, and Save it, compile it, run it, when PBForms subsequently gets focus, it prompts me to reload the file because it has been changed.
                              Conversely, changing something in PBForms means it has to be saved in order to pass the changes over to the PB IDE, although, now thinking about it I suppose CNTL-F7 might pass the changes as well.
                              I have never had a problem if I am just changing parameters in the code between Begin/End dialogs statements.
                              When adding new lines, if I really must, I place them between the End Dialog and Dialog show.

                              I took a break here and tried to add new lines in the Marked blocks and made sure that it was saved before returning to PBForms and sure enough, PBforms accepted the new line. I added lines in two marked blocks.

                              The only time I have problems is if I forget to Save/Compile/Run in the PB IDE, or Save in the PBForms IDE. Both prompth when a file is changed.

                              I do like to live with my cursor outside the Marked blocks though.
                              Rod
                              Rod
                              In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                              Comment


                              • #16
                                Chris,

                                You could also make use of PostMessage to post a custom defined message (with parameters) to the message queue before DIALOG SHOW gets called. Not real sure what you're using for properties, but DIALOG SET USER works well and has space for 8 unique numbers.
                                Adam Drake
                                PowerBASIC

                                Comment


                                • #17
                                  Originally posted by Rodney Hicks View Post
                                  ...I keep the file in both PBForms and PB.
                                  me too

                                  Originally posted by Rodney Hicks View Post
                                  ...PBforms accepted the new line.
                                  Try putting stuff after the DIALOG NEW & before CONTROL ADD, and check the source using "View.DDT code".

                                  Comment


                                  • #18
                                    Originally posted by Adam J. Drake View Post
                                    You could also make use of PostMessage to post a custom defined message (with parameters) to the message queue before DIALOG SHOW gets called.
                                    yes but it's a workaround.
                                    Originally posted by Adam J. Drake View Post
                                    Not real sure what you're using for properties
                                    see my recent posting in the source code forum
                                    Originally posted by Adam J. Drake View Post
                                    but DIALOG SET USER works well and has space for 8 unique numbers.
                                    Well, there's something comforting about giving a name to a data item, as I said somewhere else, maybe I wrote too much COBOL. Windows properties would be OK if you could only see your own properties, but the way I read it is that to successfully remove your own properties when the dialog closes you have to know what they are called, which is not always the case.

                                    Comment


                                    • #19

                                      the problem is to get info passed in to the callback proc, which takes no parameters. I don't want to use globals or a custom message
                                      Code:
                                      DIALOG NEW...
                                      
                                      DIALOG SET USER  ....
                                      
                                      CONTROL ADD....
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        (Chris breathes deeply, places palms together and utters the word "OM" while exhaling slowly)
                                        DIALOG NEW... DIALOG SET USER.... CONTROL ADD....
                                        Can cause problems when using PBFORMS
                                        (But ..#PBFORMS END DIALOG... DIALOG SET USER.... DIALOG SHOW... Is OK)
                                        I wonder if there could be a problem using Dialog Set User from a reusable code point of view - "Can I be sure that I haven't already used that user slot" - kind of thing?

                                        SetProp / GetProp maybe looks better as you can use named data items.
                                        (I suppose you could even use EnumProp to check if the name is already in use too).

                                        I know that the docs say you must remove all entries your app has added to the windows property list before destroying the window but what problems could arise if you use EnumProps to remove all props before destroying it?
                                        Rgds, Dave

                                        Comment

                                        Working...
                                        X