CheckRadioButton issue

[deltarho[1859]]

@JosepRoca

Hi José

I have another problem you may be able to help me with.

I have five radio buttons IDs 1001 to 1005, IDC_OPTION = 1001

With this:

Code: Select all

Dim As Hwnd hDlg = pWindow.hWindow
For i = 1 to NumOfPaths
  If tempString0 = tempString1(i) then
    Print IDC_OPTION,IDC_OPTION + NumOfPaths -1, IDC_OPTION + i -1
    CheckRadioButton( hDlg, IDC_OPTION, IDC_OPTION + NumOfPaths -1, IDC_OPTION + i -1 )
    Found = True
    Exit for
  End If
Next

The 'If' is true with ID = 1003 and 1001 1005 1003 gets printed.

However, none of the radio buttons gets checked when 1003 should be. Do I have a Casting problem with the identifiers?

Any ideas?

Added: I tried casting the identifiers as LONG but that didn't help.

[Josep Roca]

How do you have created the radio buttons? The first one should have the WS_GROUP style.

Code: Select all

' // Add three radio buttons (the first one should have the WS_GROUP style)
pWindow.AddControl("RadioButton", , IDC_OPTION1, "Option 1", 60, 40, 75, 23, WS_GROUP)
pWindow.AddControl("RadioButton", , IDC_OPTION2, "Option 2", 60, 60, 75, 23)
pWindow.AddControl("RadioButton", , IDC_OPTION3, "Option 3", 60, 80, 75, 23)
' // Check the second radio button
CheckRadioButton pWindow.hWindow, IDC_OPTION1, IDC_OPTION3, IDC_OPTION2

[deltarho[1859]]

The first one should have the WS_GROUP style.

It has.

When I build the form I'll try to force a CheckRadioButton.

[deltarho[1859]]

OK I forced a CheckradioButton, several values, just after creating the form in WinMain and it works.

It is not working in WndProc.

I have 'Dim As hWnd hDlg = pWindow.hWindow' in WinMain and the handle, being printed for checking, is the same in both WinMain and WndProc.

It should work in WndProc.

[Josep Roca]

> It should work in WndProc.

It depends in which message you have put the call (code not shown). If you try to check the button before it has been created, then, of course, it won't work.

[deltarho[1859]]

I don't understand that, José.

As I have just mentioned the form is created in WinMain and therefore before the first pass of WndProc. CheckRadioButton is failing in WndProc.

If I force the third button to be checked in WinMain then I get the third button checked and that may get changed in WndProc but it doesn't - CheckRadioButton in WndProc isn't doing anything as if I wasn't using it.

[PaulSquires]

I don't understand that, José.

As I have just mentioned the form is created in WinMain and therefore before the first pass of WndProc. CheckRadioButton is failing in WndProc.

If I force the third button to be checked in WinMain then I get the third button checked and that may get changed in WndProc but it doesn't - CheckRadioButton in WndProc isn't doing anything as if I wasn't using it.

If you are doing your CheckRadioButton call in WM_CREATE in WndProc then it won't work because you are doing the pWindow.AddControl calls in WinMain and, therefore, the WM_CREATE would be called only once when you do pWindow.Create

What message are you responding to in WndProc where you are setting the option button?

[Josep Roca]

> As I have just mentioned the form is created in WinMain and therefore before the first pass of WndProc.

As son as you call pWindow.Create, WndProc is called by Windows passing a WM_CREATE message. That is, before the controls have been added. SDK windows and procedures don't work in the same way that dialog boxes.

[deltarho[1859]]

You guys are going to burst out laughing at this admission.

I thought WndProc did not get called until 'Function = pWindow.DoEvents(nCmdShow)' at the end of WinMain.

As soon as you call pWindow.Create, WndProc is called

So I was using CheckRadioButton before the buttons were created.

Oh dear, it all makes sense now.

Bit of code juggling, the code I posted earlier is now in WinMain and not WndProc, and I am now getting the behaviour that I wanted.

I joined PowerBASIC after Dynamic Dialog Tools (DDT) was introduced and never got involved in SDK coding. The 'old timers' frowned at its introduction and reckoned this new easy route would haunt those that followed its path. Well, I have knocked out some fairly decent stuff with DDT in the last 16 years, using the odd SDK function not catered for in DDT, but I am now being haunted, BIG TIME.

Needless to say I have been used to WM_INITDIALOG which is a very different kettle of fish.

Thanks for your patience.

[deltarho[1859]]

You will be pleased to hear that this particular application is now completed with no errors or warnings and also does exactly what it says on the box. I will give it a good workout over the weekend and, hopefully, publish it on Monday.

I am absolutely drained and will have a nice break before I embark on another Windows GUI using FreeBASIC. Actually, that would be a good name for a horror film but not many people would understand it.

[Josep Roca]

"A dialog box is a temporary window an application creates to retrieve user input. An application typically uses dialog boxes to prompt the user for additional information for menu items. A dialog box usually contains one or more controls (child windows) with which the user enters text, chooses options, or directs the action." [MSDN].

That is, they are intended to create auxiliary dialogs to retrieve user input, not to create main windows. Windows provides predefined dialog boxes such the Open File Dialog. They send a WM_INITDIALOG message immediately before a dialog box is displayed, but after the dialog and child controls have been created. They can be modal or modeless, whereas all SDK windows are modeless. There are differences in how the messages are treated and the dialog box callback procedure never calls DefWindowProc. They also use EndDialog to end the dialog, whereas with a SDK window you use PostQuit message to exit the events loop.

Now, Mr. Zale thought that it was a good idea to build DDT using the Windows Dialog Engine instead of CreateWindowEx, something that puts the creeps to any SDK programmer that are aware of the limitations. CWindow is a light wrapper class that uses CreateWindowEx and it is 100% compatible with SDK programming. It is intended to ease the creation of SDK windows and controls, it is DPI and unicode aware, allows the creation of MDI (Multiple Document Interface) applications, to make windows scrollable, to easily work with tab pages and more. There are also classes, like CLayout, that allows to anchor child windows to a parent window (when the parent window is resized, it manages the location and size of the anchored child windows according to the new dimensions of the parent), classes to host OCXs and the WebBrowser control, graphic and image controls, GDI+ classes, etc.

And in the rest of the WinFBX framework there are tons of wrappers and classes for almost everything. And for these that prefer to use visual designers and VB-like programming, Paul is working very hard in a visual designer and an OOP framework (WinFormsX).

The main problem for PBer's is that all that have learned using DDT is completely useless with SDK programming. This is why I think that the remaining PBer's will continue using PowerBASIC and DDT forever because outside it they're lost. The arguments between DDTer's and SDKer's have ended in the PB forum because the SDKer's have left.

[deltarho[1859]]

The arguments between DDTer's and SDKer's have ended in the PB forum because the SDKer's have left.

Ha, ha. Well not quite there are some SDK folk still around. DDT got me up and running with Windows GUIs rapidly. What I should have done was to read SDK as well but I didn't and, probably, many folk followed the same path as me. I still don't have to read SDK with your WinFBX but I do need to understand the difference between DDT and SDK and I have gained some insight from you and Paul.