Best way to exchange data between a form and a unit

[Hansvb]

Hi Benny,

A bit late, but I've actually been running into the following "issue" with the function:

Code: Pascal  [Select][+][-]

1. function Execute(aMgr: ITransactionManager): boolean;

I almost never use the result and then i get a hint. It is not possible to add a second Execute procedure. That is seen as a duplicate.

I can suppress the hint or give a fictional result but there must be a better way.

[cdbc]

Hi Hans
Of course it's possible, just add it and I don't even think we'll need 'overload', 'cause they're function & procedure, so like this:

Code: Pascal  [Select][+][-]

1. { specialized transaction, sports an 'execute' method, i.e.: it knows how to commit itself ;-) }
2.   IhvbTrxExec = interface(IhvbTransaction)['{2E618F58-DE15-4A79-ADEF-C4E0A7CBECA4}']
3.     function Execute(aMgr: IhvbTransactionManager): boolean; {overload; ?}
4.     procedure Execute(aMgr: IhvbTransactionManager); {overload; ?}
5.   end; { IhvbTrxExec }

Should do just fine...
...and I'll add it to the tool too 
If you feel like it, you can also just swap the 2 declarations and just have the procedure... The choice is yours mate =^
Regards Benny

[cdbc]

Hi Hans

It is not possible to add a second Execute procedure.

You are absolutely right! Silly me 
Just got my ass handed to me by the compiler, for trying my original idea 
So, I've found a flexible solution, it involves renaming the procedure to 'ExecuteNoRes' and at the same time, surround the 2 methods with compiler defines, that let you choose which one or both, you wanna use...
- Top of 'models.intf':

Code: Pascal  [Select][+][-]

1. unit model.intf;
2. {$mode ObjFPC}{$H+}
3. {-$define dbg}
4. {$define ExecRes}   (* these 2 controls which method(s) *)
5. {-$define ExecNoRes} (* is/are in use in the IxxxTrxExec *)
6. interface  ...

...and the definition part of the same unit:

Code: Pascal  [Select][+][-]

1.   { specialized transaction, sports an 'execute' method, i.e.: it knows how to commit itself ;-)
2.     at the top of this unit you can define which or both 'Execute(NoRes)' methods you want,
3.     default is 'ExecRes' = ON, 'ExecNoRes' = OFF }
4.   InewTrxExec = interface(InewTransaction)['{2E618F58-DE15-4A79-ADEF-C4E0A7CBECA4}']
5.     {$ifdef ExecRes}function Execute(aMgr: InewTransactionManager): boolean;{$endif}
6.     {$ifdef ExecNoRes}procedure ExecuteNoRes(aMgr: InewTransactionManager);{$endif}
7.   end; { InewTrxExec }

How does that look to you?!?
It seems to compile and run, but I'd appreciate it, if you'd test it a bit before I implement it in the 'MVP-Setup' 
Thanks mate =^
Regards Benny

[Hansvb]

Hi,

I will test it but today and tomorrow i'll be home late. So i will take some time.

[cdbc]

Hi Hans
No worries mate, I'm in no hurry...
Can you live with the solution or not?!?
Regards Benny

[Hansvb]

Hi,

If I understand correctly, there will be 1 function and 1 procedure and the ifdef determines which one is used in the transaction in question. Seems fine to me.

I was still thinking about the result. Actually, that is a nice way to be able to pull the handbrake in time. I will have to use that more often but will always keep transactions where that is not necessary. So your new setup is certainly useful.

[cdbc]

Hi Hans
Yup, that's about it =^
Yes, that's why I use functions in that setup, it has its usecases  ...and if need be, the result can be ignored...
But again you're right the warnings and/or dummies not so much... 
Let's see how this flies...
Regards Benny

[cdbc]

Hi Hans
Well, I just revisited this little conundrum, after it's stewed for while in the back of my head...
The cleanest solution is right in front of us...:

Code: Pascal  [Select][+][-]

1. (* from model.intf.pas *)
2.   { specialized transaction, sports an 'execute' method, i.e.: it knows how to commit itself ;-)
3.     at the implementation you choose which or both 'Execute(NoRes)' methods you want }
4.   InewTrxExec = interface(InewTransaction)['{2E618F58-DE15-4A79-ADEF-C4E0A7CBECA4}']
5.     function Execute(aMgr: InewTransactionManager): boolean;
6.   end; { InewTrxExec }
7.   { Note: remember to switch the GUID to a different one, if you copy/paste }
8.   InewTrxExecNoRes = interface(InewTransaction)['{5E4DCDBA-8CB0-45E4-8DC3-6CD859DB4F1B}']
9.     procedure Execute(aMgr: InewTransactionManager);
10.   end; { InewTrxExecNoRes }

...and in 'model.decl':

Code: Pascal  [Select][+][-]

1.   SGUIDInewTrxExec = '{2E618F58-DE15-4A79-ADEF-C4E0A7CBECA4}';            //=^
2.   SGUIDInewTrxExecNoRes = '{5E4DCDBA-8CB0-45E4-8DC3-6CD859DB4F1B}';       //=^  

I guess, that my subconscious found the other <Messy> solution </Messy>, somewhat lacking... 
Have a nice day & regards Benny

[Hansvb]

I will try that soon in the clean setup that your tool generates. In my existing project I have to change too much I notice.

edit:

I have it working now with "InewTrxExec" in a fairly bare setup. I had just started to rename ITransaction to INewTransaction but that is not necessary at all. I will see what happens if I also want to use InewTrxExecNoRes.

[Hansvb]

I now have changed 1 transaction in my current project. The changes are much less than I initially thought.

Code: Pascal  [Select][+][-]

1. model.inf
2.  
3.   { ITrxExec }  ==> Not changed
4.   ITrxExec = interface(ITransaction)['{2E618F58-DE15-4A79-ADEF-C4E0A7CBECA4}']
5.     function Execute(aMgr: ITransactionManager): boolean;
6.   end; { ITrxExec }
7.  
8.   { ITrxExecNoRes } ==> New
9.   ITrxExecNoRes = interface(ITransaction)['{5E4DCDBA-8CB0-45E4-8DC3-6CD859DB4F1B}']
10.     procedure Execute(aMgr: ITransactionManager);
11.   end; { ITrxExecNoRes }
12.  
13.  
14. model.decl
15.   SGUIDITransactionManager = '{C75AE70E-43DA-4A76-A52D-061AFC6562D0}'; //=^     ==> Not changed
16.   SGUIDITrxExec = '{2E618F58-DE15-4A79-ADEF-C4E0A7CBECA4}';            //=^     ==> Not changed
17.   SGUIDITrxExecNoRes = '{5E4DCDBA-8CB0-45E4-8DC3-6CD859DB4F1B}';       //=^     ==> New
18.  
19. procedure TTransactionManager.CommitTransaction; = changed
20. begin
21. ...
22.       prSaveChanges:          if fTrx.GetInterface(SGUIDItrxExec, lte) then begin  ==> Not changed
23.                                 lte.Execute(Self);
24.       end;
25.       prCheckboxToggled:      if fTrx.GetInterface(SGUIDITrxExecNoRes , lte) then begin ==> changed
26.                                 lte.Execute(Self);
27.       end;  
28. end;
29.  
30.  
31.  
32.  
33. presenter.trax
34.  
35. An transaction....
36.  
37.  { TCheckboxToggleTransaction }
38.  
39.   TCheckboxToggleTransaction = class(TTransaction, ITrxExecNoRes)  ==> changed interface
40.     private
41.       Some fields...
42.     public
43.       procedure Execute(aMgr: ITransactionManager);  ==> New (was: function Execute(aMgr: ITransactionManager): boolean;  )      
44.           ...
45.          
46.        
47.  
48.  

[cdbc]

Hi Hans
YES, that's exactly how I implemented it too, in my test setup... 
The 'new' in 'InewTrxExec' is just because I named the test project 'newtrx.lpr' and thus the 3 char id became 'new'. When I implement it in 'MVP-Setup', it will follow the already established 'xxx' prefix...
I thought this was a cleaner solution, than ifdef's all over the place 
Thanks mate, for testing and input \o/
Regards Benny

[Hansvb]

This works well and is easy to adapt to an existing project. so.. good job.

[cdbc]

Thanks mate =^
Me Likey 
Regards Benny

[cdbc]

Hi Hans
...and everybody else interested...
Version 12 of 'MVP-Setup' is out now, get your copy on GitLab.

Have fun & Happy Easter everybody 
Regards Benny

[cdbc]

Hi Hans
Happy Easter.
<Spoiler Alert>
Tihi... Right, so first order on my Easter-TODO-List is finished, here's a teaser:

Code: Pascal  [Select][+][-]

1. function TTransactionManager.StartTransaction(aModReason: ptrint): TTransaction;
2. begin
3.   if not InTransaction then begin
4.     if fTraxClassMap.Contains(aModReason) then
5.       fTrx:= fTraxClassMap.GetTransactionByReason(aModReason)
6.     else case aModReason of { this is kept for now, maybe gone tomorrow :o) }
7.       prCustom: fTrx:= TTransaction.Create(aModReason); // 1 ~ doen't cause an exception, 0 does!
8.       prDataChanged: fTrx:= TTextEdit.Create(aModReason); // 1
9.       /// etc...
10.       else fTrx:= TTransaction.Create(aModReason); // 0 or anything undefined by us
11.     end;
12.   end;
13.   Result:= fTrx;
14. end;

</Spoiler Alert>
Have a nice day
Regards Benny

PS.: It's "Raining Cats and Dogs" here in Denmark