Move current entity to another unit?

[PeterPanettone 158]

Is there an MMX feature to comfortably MOVE the current entity (e.g., method) to another/new unit IN ONE STEP (without having to manually cut+paste)?

Edited December 5, 2021 by PeterPanettone

[Uwe Raabe 2064]

How would you like to have Ctrl-X - <select another tab> - Ctrl-V more comfortable?

[PeterPanettone 158]

1. Optionally create a new target unit or select the target unit from a list.

 

2. Automatically add uses statements to the target unit where needed. (Uses statements pointing to the source unit or the units required by the entity present in the source unit).

Edited December 5, 2021 by PeterPanettone

[Uwe Raabe 2064]

Despite of 2), which would even have benefits for the Cut/Paste approach (noted), I cannot see any advantage in 1). The effort to select an existing unit or create a new one is pretty much the same as opening that unit or create it with the build-in possibilities. 

 

The difference boils down to have a new functionality for this new MOVE operation, which would most likely lack a standard shortcut (which are pretty sparse in a current IDE) and thus had to be triggered from a context menu (two clicks).

 

IMHO it would end up in a new feature needing significant effort to implement while of vanishing benefit for most users.

[dummzeuch 1517]

2 hours ago, Uwe Raabe said:

which would most likely lack a standard shortcut (which are pretty sparse in a current IDE) and thus had to be triggered from a context menu (two clicks).

You could add a (configurable?) popup menu which gets one (configurable?) shortcut and add other functionality to that popup menu. I did that with GExperts and in my installation have removed most keyboard shortcuts from other experts. I used Ctrl+H for opening that menu which in the IDE is a duplicate of Ctrl+R anyway. So, calling the Uses Clause Manager Expert is Ctrl+H followed by U. OK, it's now two key combinations rather than two clicks, but I am much faster with the keyboard than with the mouse.

[Uwe Raabe 2064]

2 hours ago, dummzeuch said:

You could add a (configurable?) popup menu which gets one (configurable?) shortcut and add other functionality to that popup menu.

Actually there already are several MMX related popup menus, one being a global one reachable with Shift-Ctrl-Alt-X. So it is not adding another entry to them, but rather the task to select an existing unit or create a new one (which might be another decision point in between) and filling out the necessary parts (select a folder, enter a name), which are already available and working (almost) perfectly inside the IDE. What bothers me that the net gain is one keystroke at best - if at all.

 

I would give the uses clause thing much higher priority due to the real benefit it brings.

[PeterPanettone 158]

An example:

 

I have this method entity implemented in Unit1:

procedure TForm1.ResetHoverColor;
begin
  shpColorHover.Brush.Color := FHoverColor;
end;

I CUT this method entity and PASTE it into unit uTransparencyManager (which is part of the same project), and it becomes:

uses
  Unit1;

procedure ResetHoverColor;

implementation

procedure ResetHoverColor;
begin
  shpColorHover.Brush.Color := FHoverColor;
end;

However, to make it work without errors, I had to MANUALLY add the "Form1." prefixes:

procedure ResetHoverColor;
begin
  Form1.shpColorHover.Brush.Color := Form1.FHoverColor;
end;

1. Adding these prefixes should be done automatically by MMX!

 

PLUS: The FHoverColor variable is declared in the private section of the Unit1.TForm1 class. To make it usable in the uTransparencyManager unit, I had to MANUALLY move the declaration into the public section of the Unit1.TForm1 class.  

2. This too should be automatically done by MMX!

 

Can you please implement this? Thank you!

Edited December 16, 2021 by PeterPanettone

[Uwe Raabe 2064]

16 minutes ago, PeterPanettone said:

Can you please implement this?

No.

[PeterPanettone 158]

5 minutes ago, Uwe Raabe said:

No.

Why not? Are you in a bad mood? Don't you want to make MMX smarter and make doing things with MMX more comfortable?

Edited December 16, 2021 by PeterPanettone

[Uwe Raabe 2064]

2 minutes ago, PeterPanettone said:

Don't you want to make MMX smarter and make doing things with MMX more comfortable?

Surely I want. I just don't want to implement things that may be valuable to a single person in a special situation. There are way more things to implement that most likely bring benefit to a lot of people in several situations. My time for MMX is limited and I have to take care for what I spend it. Note that I already took this under consideration:

On 12/5/2021 at 3:49 PM, PeterPanettone said:

2. Automatically add uses statements to the target unit where needed. (Uses statements pointing to the source unit or the units required by the entity present in the source unit).

 

Regarding your requests:

26 minutes ago, PeterPanettone said:

1. Adding these prefixes should be done automatically by MMX!

This would only work on Forms and Datamodules. Frames and all other classes don't have such a global variable. Given that many people suggest to get rid of these global variables, it would be counterproductive to encourage their usage.

30 minutes ago, PeterPanettone said:

PLUS: The FHoverColor variable is declared in the private section of the Unit1.TForm1 class. To make it usable in the uTransparencyManager unit, I had to MANUALLY move the declaration into the public section of the Unit1.TForm1 class.  

2. This too should be automatically done by MMX!

Besides that this point is somewhat moot given my response to 1. Moving fields from private to public is not something that I would do without asking for consent, which will add some more user interaction to the process. It is easier to select the relevant field(s) in the class and move them to public with the available tools (like selecting public in the visibility dropdown).

 

This all does not even tackle the fact that the resulting code shown is anything but clean.

[PeterPanettone 158]

17 minutes ago, Uwe Raabe said:

it would be counterproductive to encourage their usage.

Using:

Form1.shpColorHover.Brush.Color := Form1.FHoverColor;

instead of:

shpColorHover.Brush.Color := FHoverColor;

is MANDATORY in this context! So this is not a question to "encourage" something which is SYNTACTICALLY NECESSARY!

 

It is strange that you define my code as "UNCLEAN". Has this any religious connotations?

[Dave Nottage 563]

4 hours ago, PeterPanettone said:

It is strange that you define my code as "UNCLEAN". Has this any religious connotations?

No, it doesn't:

https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29

[PeterPanettone 158]

"Code is clean if it can be understood easily – by everyone on the team."

procedure ResetHoverColor;
begin
  Form1.shpColorHover.Brush.Color := Form1.FHoverColor;
end;

I doubt that @Uwe (or anyone else) did not understand this code. I rather assume that Uwe called my code "unclean" for specific "emotional" reasons...

Edited December 16, 2021 by PeterPanettone

[Attila Kovacs 631]

buhh, I'm so tired, Uwe, can't you make MMX coding for me while I'm sleeping? pleeease!

[PeterPanettone 158]

8 minutes ago, Attila Kovacs said:

I'm so tired

Is MMX open source? I believe not. I would be happy to help. But I doubt Uwe would allow me.

Is this a Kindergarten? I hope not.

Edited December 16, 2021 by PeterPanettone

[Rollo62 539]

@PeterPanettone

Why do you insist of some special stuff, that Uwe and others already explained in detail several times.

Why not simply say "thank you very much for the insights and the valuable time you offered to me" ?

Why getting more and more agressive about people that only try to help you ?

Why do you expect other people doing something especially for you, while shouting at them ?

 

Questions, questions, questions 🤔

 

Edited December 17, 2021 by Rollo62

[PeterPanettone 158]

35 minutes ago, Rollo62 said:

insist of some special stuff

Did you read and understand what I wrote?

[Lars Fosdal 1793]

6 minutes ago, PeterPanettone said:

Did you read and understand what I wrote?

Uwe is the maintainer of the tool. His decision has been made clear.

 

Ref. code visibility challenges:

Dependency Injection (DI) can solve the challenge of doing form specific actions from a unit that ideally should not know anything about the form instance.

unit uTransparencyManager;

...

type
  TProcHandler = reference to procedure;

  THanderList<T> = class(TList<T>)
    procedure Execute;  // loop through handlers and call each of them
  end;
  
  TProcHandlerList = class(THandlerList<TProcHandler>);

var
  ResetHoverColor: TProcHandler;
  
implementation

{ THanderList<T> }

procedure THanderList<T>.Execute;
begin
  for var Handler in Self
  do try
    Handler();
  except
    // log
  end;
end;

initalization
  ResetHoverColor := TProcHandler.Create;

 

Here, TForm1 could register their method with the ResetHoverColor.Add(Self.ResetHoverColor) during FormShow and unregister with ResetHoverColor.Remove(Self.ResetHoverColor) during FormClose (or wherevere appropriate).

 

Drawbacks

 - DI requires a little scaffolding code. 

 

Benefits

 - uTransparencyManager does not need to know each form

 - TForm1 does not need to expose internal properties

 - Only the forms that actually are in use will be added to the handler list.

 - The ResetHoverColor.Execute loop can have a common exception handling wrapper to deal with misbehaving proc handler code (form = nil, errata in the injected code, etc)

 

 

[PeterPanettone 158]

12 minutes ago, Lars Fosdal said:

Dependency Injection

Interesting approach, nice code. But why introduce unnecessary complexity into something which is intrinsically simple?

[Lars Fosdal 1793]

To reap the benefits. 
 

[PeterPanettone 158]

The benefits are clear, and I agree with them. But introducing additional complexity always increases the cost of a project in terms of handling and maintenance effort.

[Uwe Raabe 2064]

17 hours ago, PeterPanettone said:

However, to make it work without errors, I had to MANUALLY add the "Form1." prefixes:

procedure ResetHoverColor;
begin
  Form1.shpColorHover.Brush.Color := Form1.FHoverColor;
end;

I cannot believe that this is real code. To me it just looks like made up.

 

If for any reason there is a need for a global procedure ResetHoverColor acting on Form1, the straight forward implementation would rather be

procedure ResetHoverColor;
begin
  Form1.ResetHoverColor;
end;

 

[PeterPanettone 158]

7 minutes ago, Uwe Raabe said:

I cannot believe that this is real code

This is a real object:

 

object shpColorHover: TShape
  Left = 26
  Top = 313
  Width = 41
  Height = 41
  Hint = 'Previews the color under the mouse pointer.'
  Brush.Color = clBtnFace
  Pen.Color = clSilver
  Pen.Width = 0
  Shape = stRoundSquare
end

 

[Uwe Raabe 2064]

10 hours ago, PeterPanettone said:

Is MMX open source? I believe not. I would be happy to help. But I doubt Uwe would allow me.

No, MMX is not open source and I don't have control over that fact.

[PeterPanettone 158]

2 minutes ago, Uwe Raabe said:

No, MMX is not open source and I don't have control over that fact.

That's a rational point. Thanks for the information.