TSynEditMarkupCtrlMouseLink for Ctrl+Alt

[Pascal]

seen this.

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

1.    act := TCustomSynEdit(SynEdit).MouseTextActions.Items[i];
2.     if (
3.   FMouseActionCommandList.IndexOf(Pointer(act.Command)) >= 0) and      <--- Command match
4.     ( (act.Option = emcoMouseLinkShow) or (not OnlyShowLink) ) and
5.     act.IsMatchingShiftState(AShift)                                         <--- and Shift matches
6.     then begin
7.  

I am holding the alt key down.

2 markups perform the test. BOTH find the action with emcMyLink1 and alt.

No, only the one with Shift = [ssAlt]

Now I release alt, and hold ctrl

2 markups perform the test. BOTH find the action with emcMyLink1 and ctrl.

No, only the one with Shift = [ssCtrl]

If both markup react to emcMyLink1,
how can one markup only find the action with alt, and the other only find the action with ctrl?

Try it.
In your demo, instead of changing the color in IsLinkable, add 2 markups, each configured with its own color.

Okay, i'll try.

Btw
Sender: TObject; // and NOT a specific subclass.
This allows the event (proc that will be assigned) to be in a unit, without dependencies.

Okay.

Just in case, I attached a draft for a plugin.
It would of course need some changes to the markup.
Such as
- being able to provide the markup with a pointer to FMouseActions
- Handling the IsLinkAble call
- exposing the markup, so user can change properties OR forwarding relevant properties (markupcolor / enable)

Thanks.

[Martin_fr]

No, only the one with Shift = [ssAlt]

Markup_1 (color red) matches emcAct1
Markup_2 (color bule) matches emcAct1

Action1: cmd=emcAct1 / shift = ctrl, no other
Action2: cmd=emcAct1 / shift = alt, no other

I want Action1 in red, and action2 in blue.

I press ALT

Both instances of Markup go through

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

1.    act := TCustomSynEdit(SynEdit).MouseTextActions.Items[i];
2.     if (
3.    // In EACH of the TWO markup, BOTH action will match the command
4.   FMouseActionCommandList.IndexOf(Pointer(act.Command)) >= 0) and  
5.  
6.    // actually option should only be tested for emcMouseLink
7.     ( (act.Option = emcoMouseLinkShow) or (not OnlyShowLink) ) and
8.  
9.     // Shift is currently ALT
10.     // So in BOTH markup Action2 will match
11.     // But I only want it to match in markup2, so only blue is triggered
12.     act.IsMatchingShiftState(AShift)
13.     then begin
14.  

[Pascal]

I've updated the demo to make SynEdit3 (rightmost) work with your setup.

[Martin_fr]

You still create only one
  ml := TSynEditMarkupMouseLink.Create(SynEdit3, []);

But my idea is that you have 2 of them

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

1.   SynEdit3.MouseTextActions.AddCommand(emcAct1, true, mbXLeft, ccSingle, cdUp, [ssCtrl], [ssShift, ssAlt, ssCtrl]);
2.   SynEdit3.MouseTextActions.AddCommand(emcAct1, true, mbXLeft, ccSingle, cdUp, [ssAlt], [ssShift, ssAlt, ssCtrl]);
3.  
4.   ml1 := TSynEditMarkupMouseLink.Create(SynEdit3, []);
5.   ml2 := TSynEditMarkupMouseLink.Create(SynEdit3, []);
6.  
7.   ml1.AddMouseActionCommand(emcAct1);
8.   ml2.AddMouseActionCommand(emcAct1);
9.  

Configure each of the 2 with a diff color and remove the color code from SynEdit3OnIsLinkable.

Now how to ensure that ml1 only reacts to ctrl?
And ml2 only to alt?

[Pascal]

Configure each of the 2 with a diff color and remove the color code from SynEdit3OnIsLinkable.

I can't remove the color code as this is the place to set the MarkupInfo (by design). The property MarkupInfo is for the old style (emShowCtrlMouseLinks and [SYNEDIT_LINK_MODIFIER]).

Of course you can separate them into two TSynEditMarkupMouseLinks but if you have conflicting MouseActionCommands you also have to check the shift state.
As always: You have to know how it works before you can use it.

In a first test i tried to use the MouseAction direct but on every ResetMouseActions the references are gone!

[Martin_fr]

Yes the idea is to separate them into as many TSynEditMarkupMouseLinks as needed.

And therefore the command alone is not enough.

Each module should have access to the full mouse action(s) to which it reacts.

So it should be given an instance of TSynEditMouseActions (it does not own this instance), then it checks all the actions on that list.
In most cases that is one action, but it can be many.

[Pascal]

So it should be given an instance of TSynEditMouseActions (it does not own this instance), then it checks all the actions on that list.
In most cases that is one action, but it can be many.

As mentioned earlier all TSynEditMouseActions get destroyed and recreated on ResetMouseActions. From this time on the
reference hold in the markup is invalid. We then have to provide a way to update the references to the newly created ones.

[Martin_fr]

With the plugin that is solved.

The plugin has its own list, and as I said you hand over a reference to the list.

[Pascal]

Ah, okay. I didn't read exactly
Of course TSynEditMouseActions is a list of TSynEditMouseAction.

So you perpare a list of TSynEditMouseActions for the plugin and the plugin creates a TSynEditMarkupMouseLink for
every TSynEditMouseAction on the list. (Sorry if i got this wrong. I didn't had a look in the plugin code so far)

[Martin_fr]

Each plugin as one list, and one markup.
So it is possible that a markup can act an several actions.

But usually the list has just one action.
And then you can have many instances of the plugin.

The plugin just holds the list. The list on the plugin is searched when a button is pressed. So the actions do NOT need to be on any of synedits own lists. (I need to make some changes to allow differentiate selected text).

-------------
For the end user:

all you do is

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

1. p := TPlugin.Create(SynEDit);
2. p.MouseActions.clear;
3. p.MouseActions.Add(....);
4. p.MarkupInfo.FrameColor....
5. // or less elegant (p.Markup is the TMarkup module)
6. p.Markup.MarkupInfo.FrameColor....
7. // and same for the event / callbacks
8.  

- the plugin creates and adds a markup
- the plugin owns the action list, but it will set a copy of it to the markup

[Martin_fr]

I am just looking at the Cursor code.

There was a missunderstanding. I meant to say that the Options do not need a Register...callback-hook.
But the cursor should have.

You made both without.

But having looked at it, it will be more complex.

It isnt a good idea to call that many functions on every pixel of mouse move.

There needs to be a cached evaluation on request, using a registered hook, and then using the cached value.

I will shortly get more info on this.

[Martin_fr]

I added a way to update the mouse cursor.

Any module can request a re-evaluation (usually if that module changes its own cursor pref).
Then all registered modules a queried, and can give their input by priority.

The reason I packed mouse info into a record is that more fields can be added later, without changing the signature of the event. (like if the textcaret is over the gutter, or text, or selection)