[fpc-pascal] Windows programming tutorials for FPC

[Paul Breneman]

On 11/12/2018 7:05 AM, Santiago A. wrote:
> 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
> 

Thanks Santiago for all you wrote!

Here is a little that I wrote (back in March 2005):
http://codenewsfast.com/cnf/article/0/permalink.art-ng1824q786

That link appears on this page:
http://www.turbocontrol.com/APro.htm

Regards,
Paul
www.ControlPascal.com