Application - recommendations?

[mijen67]

Regarding the applications GUI.

Would it be possible to create a SPA interface (single page application interface). I found the TMainMenu component and can see the benefits of having functionality hidden in drop-down menus. 

Please note, I don't want to go this route if it makes programming (and maintenance) overly complex, by example if is against the "lazarus-way" of creating gui's? Maybe it is better to do a multi-window application, where each feature is handled in separate windows,

I've created a menu I could use for the current application, please take a look at attached.

Kind regards,
Michael

[mas steindorff]

I suggest you create the GUI you prefer 1st and then worry about the code.  that's called RAD and will guide your other programing choses .  If you find your "single page" is too messy or busy, look at adding a tab page.  one suggestion: place your components on a panel.  then it will be easier to  move things around if you need to later.  I like to use 2 or more, one for buttons and edit boxes and one for the tmeno.  then use the align to client options so you can resize you window to fit different screens.  the buttons ++stay fixed and the memo can grow with the form.
a tstatusbar is also a component I always drop on a form just for the enlarged grip for form resizing 
 

[howardpc]

I noted that you used:

{$ModeSwitch advancedrecords}

and records (TStudent and TStudents) with "embedded" functions/procedures.

May I ask why you didn't go "all the way" and used a class?

There are always alternative ways to approach programming tasks. Often I simply use an approach I am familiar with, without considering alternatives too much.
Classes and a full OOP paradigm would obviously work well here.

However, using records is in some ways simpler (for instance, you don't have to instantiate your objects and remember to free them afterwards) and uses slightly less resources, so the implementation overall has a smaller memory footprint than implementing it using classes.
Records have drawbacks too. For instance I had to introduce a "filled" field to check for possible empty records when searching. Whereas if I had created a TStudentClass class, a simple check for Assigned(StudentClass) would have sufficed. Records have advantages over classes in some scenarios. You can have variant fields in records, but not in a class. In some situations that makes an implementation using a well-designed record much more memory efficient and so appreciably faster when dealing with tens of thousands of records/instances.

[mijen67]

I suggest you create the GUI you prefer 1st and then worry about the code.  that's called RAD and will guide your other programing choses .  If you find your "single page" is too messy or busy, look at adding a tab page.  one suggestion: place your components on a panel.  then it will be easier to  move things around if you need to later.  I like to use 2 or more, one for buttons and edit boxes and one for the tmeno.  then use the align to client options so you can resize you window to fit different screens.  the buttons ++stay fixed and the memo can grow with the form.
a tstatusbar is also a component I always drop on a form just for the enlarged grip for form resizing

Thanks for sharing! Very usefull hints!

[mijen67]

I noted that you used:

{$ModeSwitch advancedrecords}

and records (TStudent and TStudents) with "embedded" functions/procedures.

May I ask why you didn't go "all the way" and used a class?

There are always alternative ways to approach programming tasks. Often I simply use an approach I am familiar with, without considering alternatives too much.
Classes and a full OOP paradigm would obviously work well here.

Got it! Thanks!