Make a complete DataSet event conditional??

[Ian Branch 121]

Hi Team

D10.4.1.

I have an OnChange DataSet event in a DataModule.

The the DataModule is used by multiple apps but only a few of them need the OnChangeEvent procedure.

ATT I have this construct..

procedure dsJTDataChange(Sender: TObject; Field: TField);
begin
{$IF Defined(MyApp1) or Defined(MyApp2)}
  //
...
...
{$ENDIF}
end;

This is all working fine but I was wondering, is there any way to condition out the actual procedure in total?

Something like..

{$IF Defined(MyApp1) or Defined(MyApp2y)}
procedure dsJTDataChange(Sender: TObject; Field: TField);
begin
  //
....
....
end;
{$ENDIF}

Of course I would need to apply the same conditional to the procedure definition in the class.

{$IF Defined(MyApp1) or Defined(MyApp2)}
    procedure dsJTDataChange(Sender: TObject; Field: TField);
{$ENDIF}

the obvious problem is that if that is done then Delphi loses visibility of the dsJT OnDataChange event.  i.e. MyApp3, MyApp4, etc.

 

Is there any way around this??

Regards & TIA,

Ian

[Guest]

3 hours ago, Ian Branch said:

This is all working fine but I was wondering, is there any way to condition out the actual procedure in total?

Something like..

hi @Ian Branch

maybe you should to remember about "{$I ... }"  = INCLUDE compiler definition?

then, you can put your code in a unit separated and your projects, you can include it using your commands as you needs

But, anyway, using "{IF DEFINED( xxxx )" or anyother "in loco", is better for control and readable in your code, one time that it is used by many projects, right?

 

The RAD do it in many files, using "uses clauses" or "{$I myDef.INC} etc...

You can do it with a simple code, like:

• define constants;
• some code more specific;
• etc...
• just take care in use globally ... it can give you a headache if not properly used in the right place.

 

// unit with your conditional for use global in another units using "{$I ....}" compiler definition
{$IF DEFINED( Valuex ) 
	your code here
{$ENDIF}

 

// unit where desire insert the code special
...
   {$I myCodeInMySpecialUnit.pas}
...
// later in the project or unit you can have take care about new redefinition
myComponent.OnUpdate := a definition here to use a procedure 

hug

Edited January 3, 2021 by Guest

[Attila Kovacs 617]

Nope. Wrong side of the horse. Redesign it to be able to control it from the applications.

[Guest]

7 hours ago, Ian Branch said:

Is there any way around this??

I like the term Attila did use.

 

Events are essential part of object programming, and they are yours to assign and remove anytime, from design time to runtime, while directive will complicate the code and require unneeded extra steps from you for using/reusing the code, directives are useful but not in this case, here they are counter productive.

 

So i suggest

1) Introduce new method to that DataModule, a method to control the OnChange event (assign or remove) (enable or disable) ... in any way you see fit.

2) Use directive in different places to call and the above method and control OnChange event, always try your best to minimize the compiler directives usage in general, they can be counter productive easily and will limit the portability of your code and its reusability, for such case like OnChange above use a directive after you create the DataModule based on the application.

 

In other words for any problem that can be solved with code, use only code to make it work, leave the compiler directive as last resort, were code can't solve it or will affect the performance greatly.

[Ian Branch 121]

I too like Atilla's term, unfortunately, I don't ride horses.  ;-)

So, I ended up reviewing the suggestions here and did some more research.

Being lazy and not wishing to rewrite anything, I ended up with the following constructs...

In the Datamodule class definition I added these..

    // Local procedures defined for redirection to JTs & dsJTs at Run Time if Apps are App1 or App2.
{$IF Defined(App1) or Defined(App2)}
    procedure MydsJTDataChange(Sender: TObject; Field: TField);
    procedure MyJTAfterEdit(DataSet: TDataSet);
    procedure MyJTBeforePost(DataSet: TDataSet);
    procedure MyJTAfterPost(DataSet: TDataSet);
    procedure MyJTNewRecord(DataSet: TDataSet);
{$ENDIF}

These were of course a simple rename of the existing procedures.

Then in the Datamodule's Create Event I added the following..

  //
  // Assigning JTs & dsJTs events to local procedures at run time.
{$IF Defined(App1) or Defined(App2)}
  dsJT.OnDataChange := MydsJTDataChange;
  JT.AfterEdit := MyJTAfterEdit;
  JT.BeforePost := MyJTBeforePost;
  JT.AfterPost := MyJTAfterPost;
  JT.OnNewRecord := MyJTNewRecord;
{$ENDIF}
  //

Then of course I renamed the original procedures to My..  and wrapped them in the basic..

{$IF Defined(App1) or Defined(App2)}

....

{$ENDIF}

This may or may not meet everybody's expectations/preferences, but, it keeps the code where I have become used to where it is over the years and I have no issue with maintaining {$IF... }/{$ENDIF} constructs.

Again, I have learnt something new.  A good day.

Thank you all again for your input.

 

Regards,

Ian

[Pat Foley 50]

Quote

Nope. Wrong side of the horse. Redesign it to be able to control it from the applications.

 

Use the back of past year's calendar to draw out the redesign. Happy New Years.

 

 

 

 

Edited January 3, 2021 by Pat Foley
Added line