Mike Torrettinni

Great, thanks for this tip! I don't know how to use all features, yet, but this was annoying to always open up when I don't need it.

OK, good to know not to force it for every situation.

I have a few global units that use most of the project Forms, units to run code that needs to be run on all Forms, units, like: TranslatorUnit - translates project SettingsUnit - read/save user, project settings PrepareForNewProjectUnit - clear current working project state and initialize project to work on new data - like restarting project, but you don't need to exit and re-open it to work on new data ReleaseManagerUnit - version info related methods What these units all have in common is that they all use most of the Forms, units so they can change Form controls, data records, global classes/vars as needed. But also have methods to do same or similar things on demand! Like this: TranslatorUnit translate everything with TranslateProject, and also has a TranslateControl method that gets called by some Forms while user is using the project, so this unit needs to use the TranslatorUnit. So we have direct unit dependency, cycle. I like this design because everything related to a specific area (translation, settings...) is organized in each own unit. But this unit cycling seems to be forcing me to go back to old days, when I had everything specific to each Form, unit within that unit and I had to call TranslateMainForm, TranslateForm2, Read/Save settings MainForm, read/save settings Form2... So, it comes down to: organized unit cycling vs 'spread the code around' non-unit cycling solution. Any thoughts on this? (if my explanation makes sense)

How I solved this specific situation is that I put TranslateForm into form Create constructor. So, for now I like this situation: - TranslatorUnit doesn't reference any units anymore - one call of TranslateProject is replaced by TranslateForm(Self) call in overridden Form constructor Create - so, still 1 line of code in 1 place! even though is executed on each Form Create - on demand calls like TranslateControl can be called from any form - no more unit dependency cycles (with TranslatorUnit) result: organized code without unit dependency cycling 🙂 Thanks to all!

As Uwe said, this it not correct. If you have both units referenced in interface, it doesn't even compile: unit Unit1; interface uses Unit2; implementation end. unit Unit2; interface uses Unit1; implementation end. You need to move one reference to implementation, to actually compile - whichever one you can/need: unit Unit2; interface implementation uses Unit1; end. But this is unit dependency cycle. I have plenty of such cases in my code, and not all cases are solvable the same. But if you don't care about it, it works.

Yes, that was the idea. Unfortunately you are right, not possible, I guess.

When you have a chance, please check.

This is not working if I need to use any methods from TranslatorUnit in Unit1 or Unit2. MMX Unit dependency analyzer shows cycle: Unit1 -> TranslatorUnit -> Unit1, even if all uses are in Implementation section.

Thanks, I had a feeling this would not be possible. This unit cycling is so easy to occur, it's annoying 🙂 The check is for compile time, not runtime. Thanks, but as you predicted possible issues, I don't want to go somewhere unknown 🙂 Thanks, I will have to find another way.

I don't envy you, at all. I'm cleaning up my own code and it takes a lot for each unit, form, especially if redesign is needed. The easiest is decoupling forms, but some redesigns take time, too much time.

What is the purpose of keeping {NoLongerUsed,} in the uses clause? If it compiles, it can be removed, right? Also on StillMore {Why here?}, ... why would there be such indication? If it doesn't compile without StillMore then it should be there, no? I don't understand these concepts, I only set those units in uses clause that need to be there. I follow compiler and hints what needs to be there. If it compiles without units, I don't put them there.

A while ago I started organizing new forms, units to group and sort some methods, so I can quickly browse through methods and go where I need to go ( CTRL+click). Here is example how I organize small forms: - I like to group methods as: Form methods, Controlx methods and Other methods (these are also sorted alphabetically): - I also sort public methods TfrmProjectActivation = class(TForm) lblProjID: TLabel; edtProjId: TEdit; lblActivationID: TLabel; edtActivationID: TEdit; btnClose: TButton; btnActivate: TButton; // Form methods procedure FormCreate(Sender: TObject); procedure FormShow(Sender: TObject); // Controls methods procedure btnActivateClick(Sender: TObject); procedure btnCloseClick(Sender: TObject); // other methods procedure Activate; procedure InitializeURL; private { Private declarations } type TProjActType = (paSingle, paMultiple); var fActivationType: TProjActType; fProjID: integer; fURL: string; public { Public declarations } property ProjActivationType: TProjActType write fActivationType; property ProjID: integer write fProjID; end; I don't organize the actual code, just definitions. To me, this is useful and feels organized. Does anybody else do this? Anybody can share any thoughts on such organization, does it have any disadvantages or can share something better?

For what is worth, the new icons look great!

Those who tried 10.3.2.: does it feel like they improved error insight and code completion? Are inline variables still a problem, still marked as error?

This is a big change, as I've never tried it and from google search it seems quite tricky to make it work - first time.

Ok, maybe I can make it work, will think about it. One concern is on first run, when they can (or not yet) enter license details. So, until they enter license detail, at this time there is no control available based on license. I don;t force the license to be entered, so until they do, I can't control the project features.

Good to know I'm not the only that finds this order useful! 🙂

I never tried that, the .rc file for version info. But I did notice now that I can Add Key to the Version info... my custom details. Thanks!

Interesting, I didn't know I can set new build configurations in Project manager.

I searched but I can't seem to find any reference to this topic - or don't know what I need to look for: I was just trying to move non-global methods into Private section. Why I can't move OnClick or other control used methods into Form Private section? Instead of this: TForm6 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private public end; Into this: TForm6 = class(TForm) Button1: TButton; private procedure Button1Click(Sender: TObject); public end; It compiles OK, but when running project I get error: Error reading Button1.OnClick: Invalid property value Why is that? Also, why Button1 can't be defined in Private section, since it belongs to Form only? If I do, I get error: Class TButton not found.

Oh, OK. Good to know.

The reason I tried to put those methods in Private section, was to limit the list of all 'visible' methods, variables, to put less code to process for error insight, code completion and remove circular references. So, I might be able to do this in one of next versions. Nice! 🙂

Thanks, now I completely understand. I guess I needed to hear it three times to get it into my head @David Hoyle @David Heffernan @PeterBelow 🙂

I tested this and it works OK when private method is assigned in runtime, not in design time: I removed Button1Click from begin assgned to Button1 OnClick, and assign it in FormCreate: type TForm6 = class(TForm) Button1: TButton; procedure FormCreate(Sender: TObject); private procedure Button1Click(Sender: TObject); public end; var Form6: TForm6; implementation {$R *.dfm} procedure TForm6.FormCreate(Sender: TObject); begin Button1.OnClick := Button1Click; end; procedure TForm6.Button1Click(Sender: TObject); begin showmessage('click'); end; This also makes sense why compiler doesn't complain in cases above. I assume this so called 'streaming framework' should be updated. If I can do it in FormCreate, why it can't do while 'creating form'.

OK, thanks! I will leave them where they are.