Easy Windows API Tutorial

[aurelVZAB]

well JJ
what you think is non-standard ?
there is no need to complicate things with complex constructs
like cast lparam...etc..and of course that work...
hmm maybe you forgot that i made awinh.inc for o2 compiler....

only one thing is strange ,when i add xpManifest to exe...then icon button become frozen,,,
why that ...i am not sure ???

i need to investigate this things in FB simply because i don't use FB very often ...shame on me !!!

[jj2007]

well JJ
what you think is non-standard ?

It's not the casting (which I find silly, too - but that's another topic), it is the whole structure. A normal Windows GUI program has...
- WinMain where the main class gets registered, including the pointer to the WndProc
- the message loop is in WinMain, too
- WndProc callback function where all the WM_ messages pass
- all controls get constructed in the WM_CREATE handler.
- Wndproc ends with a return DefWindowProc(hwnd, uMsg, wParam, lParam)

The question is why it works with an entirely different structure, and if there any risks attached. It's clearly not what MSDN specifies. How do you return values from a handler, for example? There is no DefWindowProc...

[aurelVZAB]

yes JJ
you have right...
i will look better into it...

[Lothar Schirm]

This is not really necessary - fonts are not an OS-wide shared resource:

Code: Select all

DeleteObject(Font)
End

@Lothar: do you realise you woke up a really old thread? There would be a lot to comment on the OP's code, e.g. the use of "161" instead of WM_NCLBUTTONDOWN and "273" instead of WM_COMMAND; the weird omission of a WndProc callback (how can it work? a mystery...), but I would suggest to abandon this thread altogether. It is simply very idiosyncratic and confusing.

Your code is OK - maybe you should open a new thread with a similar title.

I did not want really wake up an old thread. You posted two examples on this forum in the Windows section last year: "Simple template with menu, edit control, listbox and statusbar" and "Simple tutorial to create first Windows applications". I looked at these examples and wanted to show that it is possible to do nearly the same in an easier way, even if it is not according to the MSDN standard. Maybe it would have been better to post my contribution there.

Other people in this forum write code in the same way, e.g. look at dodicat's example in viewtopic.php?f=2&t=23186&hilit=sum+of+two+numbers+GUI. I think using this approach is an acceptable way to write code for simple applications. I use a library which handles menus, buttons, edit boxes (single line and multiline), listboxes, checkboxes, radiobuttons, track bars and progress bars in the same way as in this example. And it works!

[Josep Roca]

Using "#32770" as the class name what it does is to create a dialog using the WIndows Dialog Engine. Nothing new. This technique was thought to be used mainly for auxiliary dialogs and is more limited that creating a window using your own class name. You can also use DialogBox, CreateDialog, CreateDialogIndirect or CreateDialogIndirectParam.

See: https://docs.microsoft.com/en-us/window ... atedialoga

[jj2007]

And it works!

Windows is very tolerant, but if there is no DefWindowProc, I wonder why it works. And how do you return a value from the callback?

DefWindowProcA function (winuser.h)

Calls the default window procedure to provide default processing for any window messages that an application does not process. This function ensures that every message is processed. DefWindowProc is called with the same parameters received by the window procedure.

[Josep Roca]

The Windows Dialog Engine does not use DefWindowProc. It does its own processing.

[aurelVZAB]

The Windows Dialog Engine does not use DefWindowProc. It does its own processing.

Yes that is right !

[jj2007]

The Windows Dialog Engine does not use DefWindowProc. It does its own processing.

Correct, but it's limited and also slightly messy.

[Lothar Schirm]

Josep Roca, thank you very much for your clarification.

jj2007, I appreciate your work very much, also the contributions of Xusinboy Bekchanov and you in viewtopic.php?f=6&t=28616. I was really surprised to see the short and compact code in these posts, though I do not understand all the details. Maybe we have different classes of FreeBASIC users. I am a hobby programmer and I am looking for simple solutions, but for people who want to go deeper into the Windows API stuff, your examples may be a good entry.

[jj2007]

jj2007, I appreciate your work very much, also the contributions of Xusinboy Bekchanov

Thanks, Lothar. Josep Roca is the real expert here:

Using "#32770" as the class name what it does is to create a dialog using the WIndows Dialog Engine.

I didn't know that, and it explains why it actually can work without the DefWndProc callback. But, as written earlier, the dialog engine is somewhat limited: many Windows messages (WM_...) allow to modify something by returning non-default values, and afaics this is not possible with the dialog engine - but I am ready to learn new things, Josep ;-)

[Josep Roca]

> Windows messages (WM_...) allow to modify something by returning non-default values, and afaics this is not possible with the dialog engine - but I am ready to learn new things, Josep ;-)

You can return values just using Return <something>. There are differences like receiving the WM_INITDIALOG message instead of WM_CREATE, ending modal dialogs (that don't use a message pump) calling the EndDialog API function instead of posting a WM_QUIT message, and others. The PowerBasic DDT engine uses the WIndows Dialog Engine with several tweaks. I, among others, never have liked it because of its limitations (among them not being able to write custom controls) and this caused deep divisions among the PB programmers.

When the WIndows Dialog Engine was designed, it was thought to make auxiliary dialogs for data entry or display using the then often used resource files and resource editors. Several Microsoft common dialogs like MessageBox, FindText/ReplaceText, ChooseColor, ChooseFont, PrintDlg and GetOpenFIleName/GetSaveFileName use it. The advantages were that you could design them with a resource editor, they provided resolution independence by using dialog units and the font size instead of pixels, they automatically disabled the parent window if they were modal and they triggered the OK button by pressing the return key, no matter in which field of the dialog the cursor was positioned, for easy acceptance of the data entered or the question asked. In turn, you had to use the Tab key to navigate between fields, instead of the Return and arrow keys as we did with DOS.

What it never was thought was to use it for the main window of the application, although you can do it if what it provides is enough for your needs. The remaining PowerBasic guys are happy using it. The others have changed of language.

[jj2007]

The remaining PowerBasic guys are happy using it. The others have changed of language.

I never seriously used PowerBasic (I used GfaBasic instead), but I admit it was/is a fine language, and Bob Zale was a very special guy ;-)

Anyway, for Windows GUI programming it should be the full version, not the dialogs. It's not that difficult to add a DefWindowProc, right?

[Lothar Schirm]

Anyway, for Windows GUI programming it should be the full version, not the dialogs. It's not that difficult to add a DefWindowProc, right?

Thank you for your encouragement! I took the code from "Hallo.bas" from the FreeBASIC folder "examples\gui\win32" and integrated menu and controls from my example above into the code. I added also the necessary WM_COMMAND notify messages for buttons and listbox. Works perfectly! Seems that a lot of work can be done in an easy way by "copy and paste" if you have found a basic structure.

[jj2007]

Seems that a lot of work can be done in an easy way by "copy and paste" if you have found a basic structure.

Indeed, that's what I always do: I have a template with menus (File, Open, Save) and one control in the WM_CREATE handler, plus a couple of other handlers (WM_SIZE, WM_PAINT, WM_COMMAND). I delete what is not necessary and copy the CreateWindowEx() if I need more controls. It's a question of 2 minutes to start a new GUI project. Native Windows is not that complicated, and in contrast to QT (min exe size 8MB) and other bloated crap, it's extremely efficient. You can have a GUI application at 4,096 bytes - no joke.

The learning curve may seem a bit steep, but everything is extremely well documented at M$ docs. The biggest obstacle in this specific context, FB, is obviously the ambition of portability.

This is the full source of a Windows application that loads and displays a plain text or RichTextFormat file dragged over the exe:

Code: Select all

include \masm32\MasmBasic\Res\MbGui.asm
  GuiControl MyEdit, "richedit", wCL$()
GuiEnd

53760 bytes, and under the hood it is damn complicated. But for the coder it is indeed very simple, and I wish FreeBasic would offer equally simple stuff...