Problem with PB Win 9

[Giuseppe Belziti]

Hi,
just PB Win 9 in relesead, I have updated it, but I have found now some problems: problems of focus and more. I have reistalled PB Win 8
and everything worked.
Today I have installed PB Win 9.01. The focus problems disappeared, but I have another problem, generating a system error with some simple command, that before worked very well:

SUB Config()
    SHELL"NOTEPAD2.EXE W_PMENU.CWC"
END SUB

before when this SUB end, the program continuated the flow without problems. Now, the same command give me system error. I change it with:

SUB Config()
    SHELL"NOTEPAD2.EXE W_PMENU.CWC"
    SHELL"PAY.EXE"
END SUB

and so don't give me any error.
But when the program finish, or call another program, the sistem error returns.
I have tried all, but the problem not resolved.


the command that calls the SUB is:

CONTROL ADD BUTTON, hDlg2, %IDC_BUTTON3, "Configura schermo" ,   5, 210, 70, 15 CALL Config

Can you help me?
Otherwise I reinstalling PB Win 8 that worked well.

[Bob Zale]

The problem is not with PowerBASIC, but the missing code in your CALLBACK function. You never checked the message to see if you are responding to a button click or something else. It's just pure luck that it worked in the older compiler.


Note this excerpt from the HELP File:


callbacks Prior to version 9.0 of PowerBASIC for Windows, Control Callback Functions received only %WM_COMMAND messages. Beginning with PB 9.0, %WM_NOTIFY messages are sent as well. There are many situations where these added messages will prove to be very important. If your existing callback functions are written with complete error checking (ensuring that CB.MSG = %WM_COMMAND), this minor addition will cause no problems. It just presents additional information which can be acted upon, or just ignored. However, if callbacks were written without complete error checking, some ambiguity is possible. In this case, you should either update your Control Callback code, or suppress %WM_NOTIFY messages with a #MESSAGES COMMAND metastatement.
When a Control Callback receives a click notification for a control, the callback will receive a %WM_COMMAND message in the CB.MSG variable. A common mistake made by programmers is to fail to test both CB.MSG and CB.CTLMSG parameters before responding to the message. If the message is truly generated from a click event, CB.CTLMSG will contain %BN_CLICKED. This simple test ensures that your code responds correctly to notification messages.
CALLBACK FUNCTION OkButton() AS LONG
IF CB.MSG = %WM_COMMAND AND CB.CTLMSG = %BN_CLICKED THEN
'...Process the click event here
FUNCTION = 1
END IF
END FUNCTION
It pays to be sure you are responding to the correct message in your callback. Subtle bugs can occur if you aren't very careful to notice and recognize unanticipated messages.
It should also be noted that there are ranges of notification messages that individual controls can send to the Control Callback or Dialog Callback. However, many of these messages are suppressed unless the controls have been initially assigned a "notify" style. For controls that are members of the Button class (CHECKBOX, OPTION, FRAME, etc.), this is the %BS_NOTIFY style. Please refer to the statements for additional information on notification styles for other control types.

[Giuseppe Belziti]

I'm sorry, but don't work. My CALLBACK FUNCTION was this:

CALLBACK FUNCTION OkButton()
  IF CBMSG = %WM_COMMAND AND CBCTLMSG = %BN_CLICKED THEN
    
    CONTROL GET TEXT CBHNDL, %IDTEXT TO gsUserName
    SendKeys"{TAB}"     :'simula la pressione del tasto TAB
    FUNCTION = 1
  
  END IF
END FUNCTION

I have tried to use #MESSAGES COMMAND, but don't work.

Can you do me an example?
Excuse me, but I am not of the English language certain things I do not understand well. An example is better.

[Mike Doty]

Are you calling a subprogram named "Config()" instead of a CALLBACK function?

CONTROL ADD BUTTON, hDlg2, %IDC_BUTTON3, "" ,   5, 210, 70, 15 CALL Config

[Giuseppe Belziti]

yes:

CONTROL ADD BUTTON, hDlg2, %IDC_BUTTON3, "Configura schermo" ,   5, 210, 70, 15 CALL Config

[Michael Mattias]

You need the suggested message and code test in the CONFIG function, which is a control-level CALLBACK function.

Curious how the compiler enforces that the CALL statement used in a DIALOG SHOW statement must be defined with the word "CALLBACK" in the procedure header, but does not enforce this on a control-level callback used in a CONTROL ADD statement. (???)

(I'm not a DDT guy but... doesn't the CONFIG() procedure need to either be defined with EITHER the "CALLBACK" literal in the header, or defined with the Hwnd, uMSG, wParam, Lparam parameters? If so, that would explain the 'system error' if that error is a protection fault.... passing an unexpected number of parameters on the stack would do that, you know.)

MCM

[Jeff Blakeney]

SUB Config()
    SHELL"NOTEPAD2.EXE W_PMENU.CWC"
END SUB

CONTROL ADD BUTTON, hDlg2, %IDC_BUTTON3, "Configura schermo" ,   5, 210, 70, 15 CALL Config

Can you help me?
Otherwise I reinstalling PB Win 8 that worked well.

The problem is that you are telling the CONTROL ADD statement to use your Config "SUB" as your "CALLBACK FUNCTION". CALLBACK FUNCTIONs take four 32 bit parameters and return a 32 bit value. This means 16 bytes of data are being pushed onto the stack before control is passed to your Config routine and 4 bytes of data are being pulled off when it is done. You are left with 12 bytes of data on the stack that shouldn't be there and this will almost certainly cause a system error.

I see in a later post you have a CALLBACK FUNCTION called OKButton. You need to either change the last parameter of your CONTROL ADD statement to:

CONTROL ADD BUTTON, hDlg2, %IDC_BUTTON3, "Configura schermo" ,   5, 210, 70, 15 CALL OKButton

Or change the SUB Config() line to:

CALLBACK FUNCTION Config()

I think that you were lucky that it didn't give an error in PBWin 8.

[Michael Mattias]

>I think that you were lucky that it didn't give an error in PBWin 8.

If this "number of params" thing *is* the problem....

.. then I think he was UN-lucky.

Seems to me he should have gotten a compile-time error on the CONTROL ADD statement for "Invalid callback function" and never got this far.

[Giuseppe Belziti]

OK
now all work. SUB Config() was obsolete.
Thanks

[Jeff Blakeney]

>Seems to me he should have gotten a compile-time error on the CONTROL ADD statement for "Invalid callback function" and never got this far.

I agree. There should definitely have been an error raised here seeing as the documentation explicitly states that the CALL part of a CONTROL ADD specifies a CALLBACK function name.