Delphi/Lazarus plugin template - update info about probs with Lazarus

klaus101

@Ekopalypse @rdipardo
Ekopalypse, as you took part of the discussion in
https://community.notepad-plus-plus.org/topic/22772/new-cross-platform-plugin-template-for-delphi-developers
this is for your info:
About some issues mentioned when using with Lazarus (3.6 64bit)

GDB needed as external installation?
No. One might choose, in project settings, Debugger, as debugger backend “GDB (GNU debugger” from the dropdown list
Could not start Debug:
Reason: in the HelloWrld.lpi there is the line: <Runnable Value=“False”/>
When setting the options within the IDE, it’s in project settings, Miscellaneous, “Project runnable?” (or similar)
Must be true for using the debugger.
The compiler output must be defined for the correct place, and this is not obvious:
Given, Npp is installed or unzipped into some <npp-dir>.
Npp expects the plugin dll to exist in <npp-dir>\plugins<plugin-name>
So the compiler option ‘Target-filename (-o)’ must be set to <npp-dir>\plugins<plugin-name>$NameOnly($(ProjFile))
Otherwise one might debug and step through, but he is in the wrong room.
It’s not enough to define ‘host application’ etc. For to be able to debug, it’s a Must
to set such path within IDE: project settings >> compiler settings >> Paths.

Would be good to have such within the documentation.

Now the reason for the ‘issue when shrinking the number of plugin’s submenu items’ could be found
(= when removing some items, NPP might start next with showing the plugin’s About box).
Reason: HelloWorldPlugin.pas:

const
  /// menu index of the dockable form
  //DlgMenuId = 2;
  DlgMenuId = 0;       // When shrinking the menu it might be 0 !
}

A more understandable variable (instead of a constant) name would have helped when modifying the menu. Maybe with a defaulting.

constructor THelloWorldPlugin.Create;
...
begin
  inherited;
  self.PluginName := 'Hello &World';

  DlgMenuId := 2;  // That was the original value valid before shrinking the menu
  // With defaulting and using a speaking variable name it could be something like:
  // DlgMenuIdDockingForm := DlgMenuIdDockingFormDefault;

  // ---  Now shrking the menu:
{
  PSk := MakeShortcutKey(true, false, true, $48); // CTRL + SHIFT + H
  self.AddFuncItem('&Insert "Hello, World!"', _FuncHelloWorld, PSk);
  PSk := MakeShortcutKey(false, true, true, $48); // ALT + SHIFT + H
  self.AddFuncItem('&Replace "Hello, World!"', _FuncHolaMundo, PSk);
}
  self.AddFuncItem('Load Docking &Form', _FuncHelloWorldDocking);
  DlgMenuId := 0; //   menu index of the dockable form is here now 0, not 2 !! First item!
  // DlgMenuIdDockingForm := 0;  // More understandable name

@rdipardo probably i’ll make an item in your new wiki later.

klaus101

Entered as:
https://bitbucket.org/rdipardo/delphiplugintemplate/issues/1/two-initial-issues-with-lazarus-proposals

klaus101

@rdipardo , It’s in status ‘submitted’ (not visible within the list, as not ackknowledged) since two days; did went something wrong?

klaus101

The topic is on a very goood way.
With the information given above it’s sufficiently possible to debug (Lazarus internal GDB debugger).
With the help of some custom drawing i made good steps forward in gui adpations
and meanwhile rdipardo updated the demo to show treeview theme painting too.
Details within the issue thread mentioned.
The template looks very promising!

rdipardo

@klaus101 said in Delphi/Lazarus plugin template - update info about probs with Lazarus:

[…]

  DlgMenuId := 0; //   menu index of the dockable form is here now 0, not 2 !! First item!

[…]

Answered (I hope) on Bibucket.

klaus101

Yes, answered there too … And, regarding the Gui painting, i succeeded in the essential parts.

Finally, regarding dark theme. there remained only three particular things:

The frames/borders around a treeview (borderStyle bsSingle, borderWidth 1)
appear somehow too light for me (does look a bit inconsistent)
The comboBox body was not painted in dark. -> This i could solve via:

ThemeName := ‘DarkMode_CFD’;
SetWindowTheme(ComboBox1.Handle, ThemeName, nil);

See image before/after:

But now: toolButtons with dropdown arrow: the dropdown symbol is not recognizable
(and dividers/separatos don’t look very well, but the most important thing are the dropdown arrows.
Is this solvable without painting the toolbutton from the scratch?
How is that achieved by others?

Any hints or tips would be very welcome.

rdipardo

@klaus101 said in Delphi/Lazarus plugin template - update info about probs with Lazarus:

Is this solvable without painting the toolbutton from the scratch?
How is that achieved by others?

Custom drawing non-standard components is getting beyond my expertise, unfortunately. If @dinkumoil is still maintaining his Delphi plugins, you could try asking him.

All I could find was a vague suggestion that — as feared — you may have to override the WM_PAINT message and style the dropdown icon by yourself, e.g.,

interface

uses
  Messages, ComCtrls {, ... };

TThemedToolButton = class(TToolButton)
  //...
  procedure OnWMPaint(var Msg: TMessage); message WM_PAINT;
  //...
end;

implementation

uses
  Windows {, ... };

// See https://learn.microsoft.com/windows/win32/gdi/wm-paint
procedure TThemedToolButton.OnWMPaint(var Msg: TMessage);
var
  hHDC : HDC;
  ps   : PAINTSTRUCT;
begin
  ps   := Default (PAINTSTRUCT);
  hHDC := BeginPaint (Self.Handle, @ps);
  // ...
  // All painting occurs here, between BeginPaint and EndPaint.
  // ...
  EndPaint (Self.Handle, @ps);
  Msg.result := 0;
end;

The plugin template really needs major updating to be considered dark mode capable for any type of sophisticated GUI. I can see two potential ways forward, both of them long-term projects that I won’t be undertaking right now:

a component library just for N++ plugins, with all the custom draw procedures abstracted away behind classes like TThemedToolButton, as in this quick example. The resulting library package would then become a hard dependency of the template, or else there would be a second, “application” version of the template to go with the mostly non-visual one we have now;
migrate the current template to the QT widget set, which comes with its own suite of style themes, so we should ideally only need a new hook for the NPPN_DARKMODECHANGED notification. The Double Commander file explorer implements a Windows dark theme that’s compatible with the Win10 UXTheme API or (optionally) QT 5. This would mean distributing some core QT DLLs with the plugin, and I don’t know that Delphi would be compatible.

In both cases, Windows versions older than 10.0.17763 would be forever unsupported. But then, it won’t be long before a new release of Visual Studio forces Notepad++ to do the same.

klaus101

@rdipardo, thanks a lot for the detailed response!
I’d agree fully.
“Dark mode capable for any type of sophisticated GUI” would be an own major project — surely not the task of this template or a demo.
The code of double commander (or, very close to it: “metadarkstyle” component) does loop - within the scope of the theme subclass - along all components and contains a lot of painting itself too. See e.g. the part about statusbar herein, or others.

Now, for the ToolBar, i recognized there’s no way around of custom drawing. But’s not even necessary to override WM_PAINT.
As there’s already a toolbar’s callback “OnPaintButton” provided that points the way to it. That’s basically the same as you did with the treeview’s “OnCustomDrawItem”. This one mimics parts of the (for all properties:) very long code of the Lazarus include file ‘treeview.inc’.
For the toolbutton drawing the (mostly not accessible from outside:) internal functions could be picked up, and modified somehow, from ‘toolbutton.inc’ (procedure TToolButton.Paint). By that i could achieve the required results very quickly. (Unfortunately one cannot attach a file here, otherwise i would have added a short text file with the code snippet)

The gui part is ready. With the help of this excellent template! I’d recommend it very much!

klaus101

Oh sorry, a hopefully last gui question though. The vertical Splitter, which divides the docking form from the main window.
So it’s probably set by NPP. not from within the docking form itself.
It’s known that when the (Lazarus’s splitter) property “ResizeStyle” is set to “rsUpdate” (= default). then this might cause heavy flicker when dragging the spliiter.
So normally i set the property to “rsLine”, which does “not update the sizes for the anchored controls until the resize operation is completed.” -> See example video attached

I notice just such flicker. And so my question would be:
is it possible to tell NPP to behave just analogously like as having set the splitter style to “rsLine”?

And that’s what actually the NPP’s splitter is doing with my docking form (= just like having “resize style rsUpdate” applied …)

klaus101

Not many more topics came up meanwhile. Two little things:

“TPopupMenu” won’t be drawn well in dark mode (thick light border; separators unnicely drawn). I’d assume this belongs to the amount of gui elements not yet individually handled by the code as mentioned above, right?
For the separator a quick hack could be to set it’s caption to spaces, and to disable the item. Looks better.
Did i miss something about the TPopupMenu? How does it behave in Delphi?
I have a sub-dialog (sub form) invoked from the docking form (via tool button here) and noticed it stayed light. I learnt it has to be exposed in the app-plugin as exposed func for to be subjected by the NPP theme layer. Then i call this sub-dialog via invocaton of the plugin func. Did so, and it worked fine.
But now iz’s callable from the plugin’s menu too - what might not be wanted always. Sometimes the exposure of functionality depends on a config setting though.
In short: is it possible, and how, to disable items from the plugin’s menu conditionally?