Integrating Scite as an inlined Win32 child window (in a loadable DLL)
46 views
Skip to first unread message
Rockwood Premiere
Mar 10, 2022, 4:47:13 PM3/10/22
to scite-interest
Hello Neil
This actually contains a simple question, closer to the end of the message. There's more context to this message than questions.
I was very hesitant to pen this question as the answer should be (probably) highly evident to me. However, the cautious part of my brain had reminded me of how my prior Win32 controls code needs ongoing maintenance over the past 29 years of usage. As such, before I dipped my toes too deeply into the water, I thought I'd bounce this simple question off Neil.
As some prior perspective, about a month ago I had returned to update my 22 year old simple RichEdit-based script editor. That got me thinking about adding "something just a little bit better and with more editing functionality". It is hard to believe now but it took me a serious 2 weeks of keyword searching to eventually come across Scite. Scite is such an obvious solution especially because (1) it is Win32 oriented, (2) it is so lovely and simple to compile in VS2019 and (3) I can see that Neil is actively maintaining it.
My general and original intent was to create something similar to the Scite implementation within 3ds Max and Softimage, for their script editors. Python and Lua would be my target languages once I get a binding implemented for them. But first I wanted to find a good front-end editor without a lot of third party dependencies, and Win32-oriented.
Here is the reason for my posting...
Given my long term experience with Win32 coding I want to keep my own changes to a complete minimum, in the long term, when integrating Scite. In the simplest of cases, I'd wrap it with my own Win32-based docking window and do any optional communications with it via the Director interface. This will better suit Neil's constant code updates. It would run in-lined within my app as a basic editor (DLL), mostly for myself to use. I don't expect to encounter a lot of development resistance to achieve that goal.
On the other hand, for example, in 2mins of review I've seen that 3ds Max had modified/tweaked Scite's menus and probably other aspects of the code. I'd be fine with doing that but I want to make future code maintenance manageable as Neil makes new releases.
I can make Win32 bend to my whims so I'm open to integrating Scite in any manner under the sun. I just wanted to ask Neil what he would consider to be the method of choice that he would do himself. I don't want to use Scintilla but rather Scite, and mostly unchanged except for menu variations and tweaking the various properties files.
Right now I'm expecting that I'd just simply modify the WinMain() entry code so that my docking window encapsulates and controls the start-up nature of Scite, as well as deal with some window sizing messages. I did start dabbling into that the other night. I'd have to be careful with my changes (ie. #ifdef's) so that future code releases from Neil can be easily merged.
Thank you in advance for your suggestions and also for spending decades working on this lovely set of core + UI editing features. I see this as a long term commitment on my side and hence why I'm being a tad bit careful upfront before jumping in the deep end. Prior experience can make developers cautious!
This actually contains a simple question, closer to the end of the message. There's more context to this message than questions.
I was very hesitant to pen this question as the answer should be (probably) highly evident to me. However, the cautious part of my brain had reminded me of how my prior Win32 controls code needs ongoing maintenance over the past 29 years of usage. As such, before I dipped my toes too deeply into the water, I thought I'd bounce this simple question off Neil.
As some prior perspective, about a month ago I had returned to update my 22 year old simple RichEdit-based script editor. That got me thinking about adding "something just a little bit better and with more editing functionality". It is hard to believe now but it took me a serious 2 weeks of keyword searching to eventually come across Scite. Scite is such an obvious solution especially because (1) it is Win32 oriented, (2) it is so lovely and simple to compile in VS2019 and (3) I can see that Neil is actively maintaining it.
My general and original intent was to create something similar to the Scite implementation within 3ds Max and Softimage, for their script editors. Python and Lua would be my target languages once I get a binding implemented for them. But first I wanted to find a good front-end editor without a lot of third party dependencies, and Win32-oriented.
Here is the reason for my posting...
Given my long term experience with Win32 coding I want to keep my own changes to a complete minimum, in the long term, when integrating Scite. In the simplest of cases, I'd wrap it with my own Win32-based docking window and do any optional communications with it via the Director interface. This will better suit Neil's constant code updates. It would run in-lined within my app as a basic editor (DLL), mostly for myself to use. I don't expect to encounter a lot of development resistance to achieve that goal.
On the other hand, for example, in 2mins of review I've seen that 3ds Max had modified/tweaked Scite's menus and probably other aspects of the code. I'd be fine with doing that but I want to make future code maintenance manageable as Neil makes new releases.
I can make Win32 bend to my whims so I'm open to integrating Scite in any manner under the sun. I just wanted to ask Neil what he would consider to be the method of choice that he would do himself. I don't want to use Scintilla but rather Scite, and mostly unchanged except for menu variations and tweaking the various properties files.
Right now I'm expecting that I'd just simply modify the WinMain() entry code so that my docking window encapsulates and controls the start-up nature of Scite, as well as deal with some window sizing messages. I did start dabbling into that the other night. I'd have to be careful with my changes (ie. #ifdef's) so that future code releases from Neil can be easily merged.
Thank you in advance for your suggestions and also for spending decades working on this lovely set of core + UI editing features. I see this as a long term commitment on my side and hence why I'm being a tad bit careful upfront before jumping in the deep end. Prior experience can make developers cautious!
Neil Hodgson
Mar 13, 2022, 7:05:07 PM3/13/22
to scite-interest
Rockwood Premiere:
Producing a ’SciTE control’ is something I have actively avoided as it appears to be a large open-ended project. There are limits to my ambition and workload.
> This will better suit Neil's constant code updates. It would run in-lined within my app as a basic editor (DLL), mostly for myself to use.
SciTE doesn’t really see that many substantial changes, with most updates occurring in Lexilla and Scintilla which are already quite separate.
> On the other hand, for example, in 2mins of review I've seen that 3ds Max had modified/tweaked Scite's menus and probably other aspects of the code. I'd be fine with doing that but I want to make future code maintenance manageable as Neil makes new releases.
Making the menus and toolbar more customizable would be a good direction with definitions in text files instead of platform-specific resource description or C++ source files. It should be possible for a user or packager to take the menus or toolbar, as defined in a text file, change it and point to the changed version with a property. There could even be an augmentation protocol allowing menus, menu items, and toolbar buttons to be added with a SciTEUserMenu.properties that would avoid reapplying customization after updates.
There may be reasonable changes that can be made to SciTE to make it easier to host some portion like wSciTE or wContent within a host window or as a second window in an application. The first decision here is whether the SciTE instance in your app will be a second window or will be embedded in an application window.
Since adding side bars and similar are common desires, there could be an extension point to allow this.
Neil
Producing a ’SciTE control’ is something I have actively avoided as it appears to be a large open-ended project. There are limits to my ambition and workload.
> This will better suit Neil's constant code updates. It would run in-lined within my app as a basic editor (DLL), mostly for myself to use.
> On the other hand, for example, in 2mins of review I've seen that 3ds Max had modified/tweaked Scite's menus and probably other aspects of the code. I'd be fine with doing that but I want to make future code maintenance manageable as Neil makes new releases.
There may be reasonable changes that can be made to SciTE to make it easier to host some portion like wSciTE or wContent within a host window or as a second window in an application. The first decision here is whether the SciTE instance in your app will be a second window or will be embedded in an application window.
Since adding side bars and similar are common desires, there could be an extension point to allow this.
Neil
Rockwood Premiere
Mar 17, 2022, 3:00:24 AM3/17/22
to scite-interest
Hello Neil
> The first decision here is whether the SciTE instance in your app will be a second window or will be embedded in an application window.
Thank you for taking the time out of your workday to respond to my basic (exploratory) questions. That is much appreciated.
> SciTE doesn’t really see that many substantial changes, with most updates occurring in Lexilla and Scintilla which are already quite separate.
That will leave the biggest, lasting impression on me for the long term. Having read through the change logs I had some concern about keeping ahead of future code changes. I've come to learn that it is all too easy to ignore code revisions then get into a pickle when needing to integrate years of neglected changes :-) Your comment is good to hear and I will keep that in mind for the future.
> Producing a ’SciTE control’ is something I have actively avoided as it appears to be a large open-ended project.
Just to be clear, I had no intention nor undue expectations of using SciTE as a control. That would be nice but I didn't expect to have the luxury of a quick "DLL" or ActiveX integration. On the flip side, the Visual Studio compilation was so utterly mindless as otherwise I was expecting to piece together a complex build process. At most, I just wanted to pick your brain for a few minutes just in case you had some "What I would do myself" series of comments.
> Making the menus and toolbar more customizable would be a good direction with definitions in text files....
Actually, that is a very good idea. That did not come to mind until you mentioned it. Win32 menu customization isn't too hard to implement. I will keep that in mind as that would allow me to keep SciTE "fairly intact" without having to go into the source code and customize it too much.
> The first decision here is whether the SciTE instance in your app will be a second window or will be embedded in an application window.
From my perspective, it will hopefully keep your code as-is except for (1) no WinMain and (2) parenting your window into one of my docking windows and (3) using my own message pump. I just want to keep all of those changes to a complete minimum, purely for long term code maintenance and merging with your addendums.
Thank you again for your comments. I'll try to pursue this integration in the near future. It was wonderful to come across SctiTE as otherwise I should have known more about it decades ago!
Reply all
Reply to author
Forward
0 new messages