[fpc-pascal] Windows programming tutorials for FPC

[Santiago A.]

El 02/11/18 a las 11:13, James escribió:
> I've been programming for decades with Pascal, starting with Turbo Pascal, and for a few years now with Freepascal, and even wrote really complicated console windows programs with Freepascal that do windows function calls... But now I find that I would like to write a few windows GUI programs,  and well... I'm clueless... I never learned windows GUI programming and don't have a clue about how it's done, it's always been faster and easier to just keep doing what I already understand, but now I have a few applications to write what would be much better suited to a native windows application, so,   I am wondering if there are any tutorials out there, hopefully specific to Freepascal and/or Lazarus.  I need really basic stuff like how to open a message box, or how to use windows file open, or save-as dialog boxes.. etc.. even a hello world tutorial would be helpful... ok, so ZERO windows programming experience here...   Any advice on where to start?
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Tutorials? well, that is funny. Usually there are many tutorials the 
other way around, that is, young guys that master GUI and must learn 
real programming to go further.

I know where you are, because I was there many years ago when I moved 
from DOS programming to windows programming. Someone has posted that 
programming is programming, no matter GUI or not GUI. Well, yes and no. 
You must change your paradigm a little. I suggest you to try Lazarus.

Besides tutorials  and howtos people have posted, let me tell you how I 
changed my point of view. Hope it helps you, but I don't expect much, 
everybody has his own epiphany ;-).

I started to stop seeing programs as a lineal process. I saw it more 
like an iceberg, where the window you see in the GUI is the tip, 
whenever you e.i. click a button, the program goes down, gets results 
and returns to the tip.

In console programs, you read data one by by one, a prompt and stop 
expecting an input. If the input data is wrong you ask it again. 
Creating a window with many data allowing the user is complicated, you 
must control cursor keys etc, special keys to submit the full form etc, 
you must inspect keys pressed by user in a loop. That is the "easy" part 
in GUI, using a RAD you create the window in design time, you write the 
prompts for data, the font, the position the size, the colors, the 
order,  initial values etc, you run de program, and there it is. 
(Paradoxically the more you work with GUI,  the more you do in run time 
and the less in design time). The GUI is composed by a window and 
controls, that are anything on the window, a button, a text written, a 
bevel, a box, a check box, a menu,a progress bar, a date prompt... and 
hundreds of different controls.

The GUI programming is event driver. That is, the program, the windows, 
sits there doing nothing, and reacts to what user does. The user clicks 
a button, then the  program performs what it is expected to do and 
returns to wait for a user action. That applies to user clicking a 
button, or moving the mouse, or typing a key, or even moving a window. 
Usually every control has some events, a button a "onClick" event, an 
edit box  a "on selected text", and some controls, like a label, may not 
have events. The question is that many events are irrelevant to you, the 
GUI takes care of them, i.e., you press the key TAB and GUI moves to 
other control and you needn't to write a line of code. Or a check box, 
when clicked it toggles from checked to not checked for you etc. The GUI 
does a bunch of UI things for you. When you want the program to respond 
to an event as you want, you create a function and associate it with 
that event.

The even effect is accomplished with a queue of messages. That is, when 
user click a button, a message is sent to queue, the loop waiting for 
messages picks the message from the queue and then executes the action 
associated with the click event. Usually you don't have to worry about 
this, it is transparent to you. But it is important to understand that 
if your event takes a long time, the full GUI will be irresponsive until 
it finish, all effects in the GUI are messages in the queue and until it 
picks the next messages, nothing happens it is frozen. So, in long 
process, you may disable things in the window, to inform the user he 
can't do anything, and while doing real work tell the GUI to process 
pending messages, so the user doesn't think the program is frozen. You 
can also update the window to show progress, but you also must say GUI 
to process messages queue, because you updates are just messages to the 
window.

A RAD like Lazarus, creates a form, a window, and lets you drop 
controls, resize them easily, change some properties, etc. The RAD show 
you the events each control has, when you click them, it creates am 
empty function and brings to front the editor to let you write the real 
code.

It is an over simplification, but hope it has helped a little. But well, 
as I said, everybody has his own epiphany. Good luck

-- 
Saludos

Santiago A.