No announcement yet.

Mysterious callback function problem,

  • Filter
  • Time
  • Show
Clear All
new posts

  • Mysterious callback function problem,

    'Code for a button control and related callback function follow.
    'I'm getting an "impossible" result (see 'problem, described
    ' below). Any explanation of how I can stop this from happening,
    ' or why it might be happening would be very much appreciated.
    'The program seemed to be running perfectly, until I "filled in"
    'some code in the previously empty CALLBACK function below, as
    'it had been created by EZGUI. Bug in PBDLL60? or EZGUI?

    %FORM1_SELECTCORPBUTTON = 1 'Control ID number

    CONTROL ADD BUTTON, hForm1&, %FORM1_SELECTCORPBUTTON, "Select &Corp.", 148, 69,_

    'Related Callback Function, which is called ONLY from the one
    'button control above, and from absolutely nowhere else in the

    ' ------------------------------------------------
    MSGBOX "Why am I seeing this message now, when I didn't click this or any other button?"

    END IF

    END IF

    END IF
    ' ------------------------------------------------

    'Problem: Each time I enter a stock symbol in a text box
    ' control, in the same dialog (hForm1&) as the above button,
    ' the program calls the above callback, displaying the MSGBOX
    ' message I put in as a diagnostic, and then (unwanted!) it
    ' calls the LookUpSymBox( ) SUB to do a lookup. I cannot for
    ' the life of me understand how this is occurring, since the
    ' button in question is not being clicked, and thus nothing
    ' should be happening in the button's CALLBACK FUNCTION. When
    ' I DO click on that button, the callback works then, too (as it
    ' should, in that case), calling the LookUpSymBox() SUB.

    ' I noted that if I changed the value of %FORM1_SELECTCORPBUTTON = 1
    ' constant to something other than =1, and assigned the value =1
    ' to a different button control, whicho update a stock ticker string,
    ' then each time I enter a symbol in the Textbox control, the
    ' callback for the OTHER (stock ticker button) is hit instead,
    ' which is less of a problem, but is still a mystery.

    'The obvious kludge solution was to make sure none of the control ID
    ' constants for this dialog had a value of 1, but that creates
    ' another strange problem: Pressing the enter key after entering
    ' stock symbols in the text box no longer has any effect, unless
    ' one of the other controls in the same dialog has the constant ID%
    ' value of 1, for some odd reason. Needless to say, nothing in the
    ' PBDLL documentation mentions that you must assign the value =1
    ' to at least one control (not a label -- that doesn't work) in
    ' the dialog in question, rather than some other unique, arbitrary
    ' value, or else a textbox for data entry won't work properly
    ' when the ENTER key is pressed.


  • #2
    I believe there are two control ID's that are fixed, 1 for %IDOK
    and 2 for %IDCANCEL, so probably best to avoid Id values 1 and 2
    all together there..



    • #3
      Yes, thanks Borje, that was my thought, so I renumbered all my
      control ID's up from 100. But now I see why EZGUI assigns a "1"
      value to the default button (typically an OK or GO) button
      in a dialog. I did that, and it now works (when enter is pressed)
      after typing text into the text entry box, it's as though the
      user entered the text and then clicked on the related "GO" or
      "OK" button, to "make it so").

      But I still find that if I don't assign an %ID=1 to the OK
      button in the dialog, the button style %BS_DEFPUSHBUTTON
      for that doesn't seem to work any longer, and pressing "Enter"
      after typing in text has no apparent effect.

      So I've solved the mystery, at least in part. Thanks.



      • #4
        Mike, there are any number of reasons why this effect could be occurring. We'd need to see the code to be able to offer constructive suggestions, or we'd just be guessing!

        PowerBASIC Support
        mailto:[email protected][email protected]</A>
        mailto:[email protected]


        • #5
          Thanks, Lance, but I've simply rewritten all my callbacks so that
          entering text in a textbox, followed by pressing the ENTER key,
          will be read as a buttonclick in callback for the "GO" or "OK"
          button that accompanies the textbox in the same dialog.

          That works as long as I assign a constant value (%ID number)
          of 1 (only) to the GO or OK button. I don't know if that
          is how it is supposed to work, but it does, so it's not a
          problem now that I've figured that out. Changing the ID
          to any value but one means that pressing ENTER isn't detected
          any longer by any of the callbacks in that dialog, if none of
          controls for that callback have an %ID=1.

          Unfortunately, this is already a 300k program, and extremely
          complex, so there's nothing short of the whole program I could
          post or send you for analysis of this problem (which is no
          longer a serious problem).

          Thanks, anyway.



          • #6
            Hi Mike,
            I experienced the same "dead default key" too. I thought it was
            a Win2000 thing, so I didn't pursue it til I saw your post. I
            changed the ID of my button to 1 and it worked as you said. Then
            I found this in MSDN:

            "You use the defined symbol IDOK for an OK button in your dialog.
            When the user presses ENTER, the system sends your dialog
            procedure a message as if the OK button had been pressed.
            IDOK has an ID value of 1.
            You use IDCANCEL for a Cancel button in your dialog. When the
            user presses ESC, it's as if the Cancel button had been pressed.
            IDCANCEL has an ID value of 2."

            Anyway, thanks for figuring that out!

            [email protected]


            • #7
              Ah, thanks, Wyman. That's very helpful. I hadn't figured out
              the Esc key yet. Now it all makes sense. I'm a new Windows
              programmer, and don't have the MSDN, or any other references, so
              I'm flying in the dark, I guess.



              • #8
                Hi Mike,
                The MSDN Library's online at:

                Also you can download the Platform SDK which is the
                "Windows Essentials" from:

                All this stuff's free...and somewhat random. If you look in the
                Powerbasic FAQ you'll find book suggestions (in fact, I expect
                Lance'll be inserting his Petzold Plug in here
                Also, within the Library (either online or the Platform SDK if you
                download it) is what I thought a good place to start for an
                Platform SDK
                     |_User Interface Services
                                 |_ Windows User Interface
                Inside that subsection it covers dialog boxes and windows. It helped
                me anyways (probably mostly convinced me that I needed several really
                good books). Hope that helps? Good Luck, Fellow Windows Beginner!!

                [email protected]

                [This message has been edited by Wyman A Belts (edited January 22, 2001).]


                • #9
                  Um.. I may be missing something here, but shouldn't you use %BS_DEFAULT instead of %BS_DEFPUSHBUTTON if you want the button to take action with the ENTER key? Does %BS_DEFAULT also require an ID of 1?

                  Bernard Ertl

                  Bernard Ertl
                  InterPlan Systems


                  • #10
                    Yes, very helpful. I didn't realize MicroSoft gave away
                    anything for free to developers.

                    Thanks again, Wyman.



                    • #11
                      That was new to me, Bernard. I tried using %BS_DEFAULT for the
                      Textbox control, and it does appear to cause the enter key to
                      work (without having to have a related "Go" button with a
                      value=1 and using the %BS_DEFPUSHBUTTON style, as I was doing.

                      However, I still note that if I change the %ID of the textbox to
                      anything but 1 (unless I define another control in the same
                      dialog as 1, such as the GO button), the Enter key no longer

                      See Wyman's comment on my question yesterday re using values of
                      1 (%IDOK) for Enter key and 2 (%IDCANCEL) for Esc key, where
                      using it to cancel in lieu of point and click. This is starting
                      to make a bit of sense now.




                      • #12
                        %bs_defpushbutton   = &h1&
                        %bs_default         = %bs_defpushbutton
                        these _button_ styles are not suitable for edit controls... numerically, applying this style to the edit control gives you the style %es_center.

                        ps: i forgot to plug the petzold and rector/newcomer books (i'd hate to disappoint anyone!) take a look at "win32 reference books"

                        powerbasic support
                        mailto:[email protected][email protected]</a>
                        mailto:[email protected]


                        • #13
                          Bye the way, the IDOK jobadoo is discussed on page 507 of Petzold
                          5th Edition!!

                          [email protected]


                          • #14
                            Administrator posted January 22, 2001 02:26 PM

                            BS_DEFPUSHBUTTON = &H1&%BS_DEFAULT = %BS_DEFPUSHBUTTON
                            These _button_ styles are not suitable for Edit controls...
                            numerically, applying this style to the edit control gives you
                            the style %ES_CENTER

                            Yes, so I noticed, Lance, when I tried using those with an
                            editable text box, which was not suitable. Thanks

                            -- Mike Jenkins