Lazarus Suggestion: Form Designer Ideas (non visual components)

[Tony Stone]

I have some forms with many non-visual components. Right now, I know we can toggle their visibility, but I haven't found a hotkey for this, or a way to set one up. If there's a hotkey I'm missing, I'd love to know how to do it.

Also, I've got a suggestion for handling these components better(I think). What about a sub menu in the forms context menu that displays a grid view of all non-visual components on the form?  This way, we'd have all non-visual components neatly organized in one spot, making it quick to find and view what non visual components are on a form.  There has been times I placed one and it ended up way off the visual area of the form as I must have placed it at some point before shrinking the form down.  Now I also understand they are kind of all grouped together at the bottom of the object inspector list... but I feel like a quick view of what I have on the form using its components icon could be very handy.

This setup would mean:

All non-visual components are in one place - less clutter, more organization.
Easy editing and configuration - click an icon, and it's highlighted in the Object Inspector.
A clear visual of what's in use...

I really think this would be more of a logical setup, especially on forms with many non visual components.  I am also curious if there is some other reason that I may be missing or ignorant to that would require a non visual components postion on a form to even be tracked?  Or is it just simply because this is the way Delphi did it and other IDEs?  It has always seemed so odd to me and actually annoys me often when all of the non visual icons clutter my form.

Since I don't think this is a feature the developers will implement my next ideal solution would be for there to be a hotkey to toggle the visibility of all components and it would be nice if it was persistent.  When i reopen a Lazarus project where i had hidden the NVC's they end up showing up again.

[TRon]

Hi Tony,

That is why you can use a Datamodule and while that wiki link states it is meant for database components that is not the case. You can use a datamodule to group any kind of non-visual components, methods, subroutines and whatever else you wish to group together.

[Tony Stone]

You know now that you mention it this was actually suggested to me before but I have forgotten. But I do recall try again when it was suggested to me and I think I still felt it should be more streamlined but I will look into it again especially this was probably a year or more ago that someone on the forum suggested that to me. Thanks

[VisualLab]

Hi Tony,

That is why you can use a Datamodule and while that wiki link states it is meant for database components that is not the case. You can use a datamodule to group any kind of non-visual components, methods, subroutines and whatever else you wish to group together.

It is also worth taking a look at the documentation of the TDataModule class. It is only slightly more extensive than TComponent (mainly with features related to the design stage).

You know now that you mention it this was actually suggested to me before but I have forgotten. But I do recall try again when it was suggested to me and I think I still felt it should be more streamlined but I will look into it again especially this was probably a year or more ago that someone on the forum suggested that to me. Thanks

Maybe you mean the approach used in Visual Studio? There, in the form editor, non-visual components are placed in a separate area below the form. Is this a better (more convenient) solution? Hard to say. If there are many non-visual components in the form at the design stage, this area will have to be scrolled using scroll bars anyway. Moreover, in the form editor in VS, each non-visual component takes up more space than those in Delphi/Lazarus.

[Tony Stone]

Maybe you mean the approach used in Visual Studio? There, in the form editor, non-visual components are placed in a separate area below the form. Is this a better (more convenient) solution? Hard to say. If there are many non-visual components in the form at the design stage, this area will have to be scrolled using scroll bars anyway. Moreover, in the form editor in VS, each non-visual component takes up more space than those in Delphi/Lazarus.

I am not sure how Visual Studio does it.  But I just keep imagining a context menu that pops open a small 200 x 200ish gridview of the NVC's used.  But I am gonna look at the data modules again when I get home.  Maybe it is time for me to expand my knowledge into other features available to me such as the data modules.  I think my feeling when I tried data modules is that i was adding things to my final executeable program that were uneccesary justto make design time more stream lined. 

[Tony Stone]

Well, I gave the DataModule solution another go, and for me, it's just not a reasonable solution. Moving all my code to the DataModule unit for associated events then becomes problematic when trying to reference items in the main form. This is because you need to include the main form's unit in your 'uses' section, which obviously causes a circular reference error.

To me, this approach feels like using a component intended for runtime processes to address a shortfall in the IDE's design. Frankly, it's just not a solution for what should be a basic functionality of the IDE. I understand my view might be in the minority, and I'm okay with that. Maybe someday, I'll take another stab at making my own modifications to Lazarus (though most of the code there is way over my head), and implement a more elegant way to organize the clutter of non-visual components.

For now, I need to get back to removing this DataModule and putting everything back in place.  lol

[Joanna from IRC]

I use the data module for my sqlite related stuff. I made the data module from the beginning because I wanted to be able to reuse the code.

Applications evolve over time and don’t always scale well.

I have made many design mistakes because of not knowing any better. I know very well how annoying it is to tear apart and redo a project that works perfectly well. However, If a project is not designed well it will only get more tangled and confusing as it expands with new features.

My suggestion is to not modify your existing project at all but to make a new project and copy code/reuse files from current project into the new one with a better design. Maybe reevaluate the overall design and make changes to it.

I once had my layout manager and factory combined In one unit and that was a lot to Untangle. 

[TRon]

Well, I gave the DataModule solution another go, and for me, it's just not a reasonable solution. Moving all my code to the DataModule unit for associated events then becomes problematic when trying to reference items in the main form. This is because you need to include the main form's unit in your 'uses' section, which obviously causes a circular reference error.

Solving circular unit reference is discussed in the reference manual topic unit dependencies.

To me, this approach feels like using a component intended for runtime processes to address a shortfall in the IDE's design.

Frankly, it's just not a solution for what should be a basic functionality of the IDE.

 I understand my view might be in the minority, and I'm okay with that. Maybe someday, I'll take another stab at making my own modifications to Lazarus (though most of the code there is way over my head), and implement a more elegant way to organize the clutter of non-visual components.

It is imo not a shortfall, rather a friendly nudge to make you think about designing your programs another way. But you are ofc in your right to disagree with that.

Hopefully you are aware that also non-visual components can be created at runtime ? That way you do not have any clutter at all 

For now, I need to get back to removing this DataModule and putting everything back in place.  lol

If you are working a with databases (yes, there is that reference again) then the only sane way to keep things organized is by using a datamodule (at least when you are using the designer which not everyone does) and it works (without circular reference errors). So while that might not be the perfect solution that you perhaps envision I would urge/suggest to give it a proper try (if only to get better acquainted to datamodules and their use).

Regarding to your initial idea, you could always try and drop that to Lazarus developers (e.g. make a feature request by filing an issue) to see what they think about it (though I realize that was intended with your original post but it does not seem to generate the response you had in mind but that might perhaps be because of the holidays).

[Joanna from IRC]

When I use data module I create it and use the variables within it from other units. The code in data module only references the database.
 I don’t know how well this setup would work for other types of non visual components but I’ve never had circular reference problems.

[Tony Stone]

Thanks TRon.. yes I do know how to deal with the circular reference... I only mentioned it to show that this solution creates yet another hurdle for a beginner to deal with if they were trying to do something as simple as keep a design time form clean and organized like the IDE should be doing for them.    I mean an IDE is supposed to stream line the development process and help you be more organized after all, right?  But yeah... I don't disagree with you that a dataModule is a decent solution.  I personally feel like it breaks up much code though... you end up having form related code in a separate unit now.  I am not sure I think that is organized.   Again... I am no expert at all... these are just my opinions.   
And yes I suppose your idea of creating at run time is a solution as well... however then, whats the point of an IDE?     

When it comes to things like how software should work I am not always stubborn and adamant  about being right but this one I have to dig my heals in. 

The current way of putting NVC's on a form serves absolutely no purpose and only takes away from the power and usefulness of a good GUI design tool. (yes again my opnion) 

Not trying to be too harsh but I just had to let it be known that, it is in my opinion the weirdest and stupidest thing to display them on a form. lol  I also understand it probably bothers me more than most other people but some things i get passionate about.  I appreciate all the work developers have put into Lazarus...

[TRon]

And yes I suppose your idea of creating at run time is a solution as well... however then, whats the point of an IDE?     

Once upin a time, there did not even exist an IDE (RAD did not even exist) and you had to do everything manually 

Not trying to be too harsh but I just had to let it be known that, it is in my opinion the weirdest and stupidest thing to display them on a form. lol  I also understand it probably bothers me more than most other people but some things i get passionate about.  I appreciate all the work developers have put into Lazarus...

The problem here, I guess, is that when the concept of Datamodule was introduced, you get used to it over time and you don't know any better.

If I remember correctly there was a 3th party designtime component for Delphi back in the day that allowed you to (even) categorize groups of components (including the non visual ones) so in that regards I am fully aware that I am just stuck and fall back doing things the way I've learned them to do    but I can fully understand that this is perhaps a bit odd/strange if you are not used to it.

Also, in case you haven't considered them already, note the availability of the TAction and TActionList components that are able to help you organize your code-base in other ways.

Like I wrote before, if you are passionate about this topic/feature (usually accompanied with some good arguments) then please do consider to file an issue and make a request for such a feature. The problem with most of these kind of requests is that when it does not add anything significant then such a feature request can be ignored (e.g. people able to implement such a feature usually have their own priorities, and Lazarus is a very big project so there is much to do).

[Tony Stone]

Once upin a time, there did not even exist an IDE (RAD did not even exist) and you had to do everything manually 

Thank god we are beyond those days!  This is only my hobby because Lazarus makes it quick and easy to build useful programs! (more importantly for me it is FUN!) 

Also, in case you haven't considered them already, note the availability of the TAction and TActionList components that are able to help you organize your code-base in other ways.

Yes I have briefly read about and looked at examples of their usage in the past.  I think you are right and it's another thing I should learn to use.

Like I wrote before, if you are passionate about this topic/feature (usually accompanied with some good arguments) then please do consider to file an issue and make a request for such a feature.

I may try to implement something myself but you are right...  Lazarus is a huge project and I have gone through it's source and have not been able to wrap my head around any of it.  I have tried several times to fix a bug in the code editor where if I am selecting/highlighting text and I move my mouse over a keyword that triggers a hint it causes the selection to stop.  I thought I fixed it once then realized i had basically made hints never work! haha  I am great at breaking code... not fixing it.