Mike Torrettinni

Thanks, but is not really using record methods. or dealing with pointers like I do. Perhaps you were trying to point out something else?

Good catch 🙂

Yes, I have other rec structures possible.

Hm... it compiles and runs here just fine. Or is it just luck and will fail sooner or later? Maybe I should add more details: I have PINIRec = ^TINIRec; and RecPointer is set with: type PINIRec = ^TINIRec; var vRecPointer: PINIRec; begin ... New(vRecPointer); vRecPointer^ := Default(TINIRec); ...// here set vRecPointer values from INILine... ComparedData[x].RecPointer := @vRecPointer^; Does this make sense?

So I have 2 sub classes with a lot of methods, that are defined as virtual or virtual abstract methods in base class. But this is just a waste of time to define them in base class, when they need to be overriden in sub class, too. At this moment, the only real information completely independent of sub classes are: Error messages, IsLoadingDone, IsComparingDone, NoOfDifferences, File1, File2 and such... basically nothing of real value that would warrant a base class. I just started with classes, please don't suggest Interfaces 🙂 It makes much more sense to have 2 separate classes and common utility methods that do the work based on fCompareType parameter. This makes sense.

@Lars Fosdal, thank s for the original idea, but I have a dilemma here what to do: if I add a 3WayCompare: constructor TINIComparer3Way.Create; begin Inherited; fCompareType := cmt3WayCompare; end; Now the main class will do all the work based on fCompareType , all the comparison, preparing results for visual display, reporting and such - so a lot of: if fCompareType = cmt2WayCompare then ... else if fCompareType = cmt3WayCompare then ... All good, makes sense. But now we could say that the base class implements the details of sub class. Isn't this wrong approach, shouldn't base class 'not know' anything about the implementation of it's sub classes? If base class should be oblivious of sub classes, this means I need to implement everything in sub classes where all the methods are very similar, just slight difference. But when everything is implemented in sub classes, except for only 1 or 2 common methods stay in base class, so why the need for base class, at all? Same goes for presentation layer: if I want to display/export/report 3WayCompare with just 1 record field more than 2WayCompare, it's again a lot of IFs in 1 presentation class, or 2 completely separate presentation classes with their own methods. The more I read about class inheritance, the more confused I get, because examples like TAnimal <- TDog, TCat makes absolute sense. but when you need a little more implementation details, it doesn't make sense at all. Any feedback is appreciated!

Not sure how to describe the issue, so here is the strange behavior: When I double click the VirtualStringTree1Node to ShowMessage('Node dbl clicked'), I need to click twice (the Close button - X ) to close the form, after the message window is closed. Simple example of new form with VirtualStringTree1 control: procedure TForm8.FormCreate(Sender: TObject); begin VirtualStringTree1.RootNodeCount := 1; end; procedure TForm8.VirtualStringTree1NodeDblClick(Sender: TBaseVirtualTree; const HitInfo: THitInfo); begin ShowMessage('NODE dbl clicked'); end; I tried Application.ProcessMessages after ShowMessage, no change, still need 2 clicks to close the form. Any ideas what am I doing wrong? VTVersion = 7.2.1

I ended up using PostMessage: TForm1 ... const WM_OpenRealTimeMonitoringForm = WM_APP + 1; private procedure OpenRealTimeMonitoringForm(var Message: TMessage); message WM_OpenRealTimeMonitoringForm; procedure TForm1.VSTOnNodeDblClick(Sender: TBaseVirtualTree; const HitInfo: THitInfo); begin // Use PostMessage to correclty handle DblClick, to avoid mouse-event be eaten by modal window... PostMessage(Self.Handle, WM_OpenRealTimeMonitoringForm, 0, 0); end; procedure TForm1.OpenRealTimeMonitoringForm(var Message: TMessage); begin ... Form.Show; end;

Just found this thread, I guess a similar issue: Windows is hungry and eats mouse events 🙂

Thanks! Wow, these modal windows are killing me in last few days!

Thanks! So I need to 'raise' another MouseUp event?

Something new and I will probably go through a few variations until I end up with something I'm OK with. You should see how I choose icons for my projects, I can get crazy picky for that perfect icon and color... 🙂

Great, thanks! Also annoying thing about multiple forms opened is that ShowMessage can show up behind the form, and since it's modal, sometimes you can't access it to close it - annoying. Saw and interesting example where the Form was dimmed, but the notification message was not - very noticeable and no modal windows.

So, what I'm trying to do: I have monitoring application and can monitor different different data, files, folders, disks... main form lists all available services to monitor and user selects which ones he wants to monitor and opens up new form with all the details. So, user can have multiple forms open and can work with the monitored data. It can happen that one of the monitored services need attention or connection get lost. In this case a ShowMessage (or new Form.ShowModal) is supposed to alert user with message, while other forms should continue monitoring. User can then decide to reconnect or close the form that is showing an alert, while other should just continue monitoring. So, a modal window that blocks only the form it was called from, would be really useful in this case. Any ideas?

Ok, I see. So, unless I create new process for each new form, I can't prevent modal mode to block all opened forms?

Thanks for all the feedback! Single constructor Create from now on 🙂

I see 2 options how to organize code for cross platform deployment: - units stay as the are now (based on content: utilities, support, data, visual...) and use IFDEF in methods all over the code as necessary Delphi uses this approach in their units, but it can get a bit tedious browsing through code with all the IFDEF's - split units based on platform, so we end up with Utilities -> WinUtilities, LinuxUtilities and so on... and use IFDEF in uses to use appropriate unit This seems good, since you can end up with WinUtilities, WinExports, WinVisual, LinuxUtilities, LinuxBGService.... Any recommendations on which approach to use?

Thanks, the reason for separate uINIComparerStructure is that many other units will do the 'work', like I have visual presentation class, TPresentationLink, that links VirtualStringTree and compare results - in this case TPresentationLink unit has to know the basic types. TINIComparer = class ... fPresentationLink: TPresentationLink; // in uINIDataLink procedure AssignPresentationLink(aVST1, aVST2: TObject); procedure TINIComparer.AssignPresentationLink(aVST1, aVST2: TObject); begin fPresentationLink := TPresentationLink.Create(aVST1, aVST2, GetData1, GetData2); end; So, in Form1 I set fINIComparer.AssignPresentationLink(vstINI1, vstINI2); and have access to results in VSTs. The naming of units will change with project evolving.

I'm loading a lot of data from files, so I was testing the difference between TList and TArray memory consumption. And it seems TList uses a lot more memory. This is my simple test: procedure TForm8.Button1Click(Sender: TObject); type TDataRec = record ID: integer; Name: string; end; var vDataRec: TDataRec; vDataList: TList<TDataRec>; vArray: TArray<TDataRec>; i, vMax: integer; begin vMax := 10000000; vDataList := TList<TDataRec>.Create; try for i := 1 to vMax do begin vDataRec := Default(TDataRec); vDataRec.ID := i; vDataRec.Name := 'X'; vDataList.Add(vDataRec); end; finally vDataList.Free; end; SetLength(vArray, vMax); for i := 0 to vMax-1 do begin vArray[i].ID := i; vArray[i].Name := 'X'; end; vArray := nil; end; And here are results as I see them in Task Manager in Memory (active private working set) column - I believe this is the one that can be monitored when/if Out of memory error occurs. TList<TDataRec>: Starting memory: 3,716 K Filled list: 369,488 K Consumption: 365,772 K TArray<TDataRec>: Starting memory: 5,548 K Filled list: 316,588 K Consumption: 311,040 K TList<TDataRec> vs TArray<TDataRec> = 54,732 K = 17% 17% is not extreme, but it is significant difference. But! If the TDataRec only has 1 integer: TDataRec = record ID: integer; end; Now the difference is unacceptable: TList<TDataRec>: Starting memory: 3,720 K Filled list: 69,700 K Consumption: 65,980 K TArray<TDataRec>: Starting memory: 4,208 K Filled list: 43,272 K Consumption: 39,064 K TList<TDataRec> vs TArray<TDataRec> = 26,916 K = 68% 68% seems extreme difference! Is this normal, or am I missing something very obvious?

Thanks, so each type of comparer would be its own class, derived from main class. OK, not something I considered.

My idea was to design is as closed unit as possible, so it can be used by Form for visual presentation, as background service to export results and so on. Perhaps a little overkill.

Perhaps I wasn't focused on the real problem: unit uINIComparerStructure has TCompareType + other INI related types. unit uINIComparer has TINIComparer class; and uses uINIComparerStructure unit. (other units also use uINIComparerStructure since they deal with INI content as needed) Form1 uses uINIComparer unit to use TINIComparer class. I would like to hide uINIComparerStructure unit from Form1, so I don't expose all types that Form1 doesn't need to know about.

No, I want to hide the TCompareOption from Form1 and other units that will use TINIComparer class. Of course class unit has to know the options.

Thanks! So, if compare options are: TCompareType = (cmt2WayCompare, cmt3WayCompare, cmtHeadersOnly, cmt3WayMerge ...); I could have: constructor Create( compare option, Ini1, Ini2) but this means that main form (or who ever will use the class) has to use the unit where TCompareType is defined. So, I wanted to avoid with with just creating multiple constructors and the main form doesn't need to know the options, just the name of constructor should be OK. constructor Create( compare option, Ini1, Ini2) or constructor Create2WayCompare(Ini1, Ini2) constructor Create3WayCompare(Ini1, Ini2) constructor Create3WayMerge(Ini1, Ini2) ... So, the whole point was use as little units as possible.

@Attila Kovacs Is my question so bad, you can't give me a little more details?