my editor project

[zedd151]

Okay, I have a nice clean simple stripped down editor now, which I will use as the testbed for the plugin interface and menu handling code. This is the editor, without any of that code yet. (a template). I will work on the menu handling functions first... 
attachment removed. I am currently revising the ini file and menu processing code

[zedd151]

In the programs ini file plugins will be listed under the section [Plugins]. (where else)
Due to the nature of the design would not be able to use "GetPrivateProfileString" for the obvious reason that the editor has no knowledge of what plugins might be used, a no-brainer. Therefore we must parse for the plugin names ourself.
The plugins will be listed in the format

Code: [Select]

[Plugins]
ASM Comment=/plugins/ASMcomment.dll
Another Plug=/plugins=AnotherPlug.dll
in the ini file. Where the Key is the name to appear on the editors Plugin menu. The Value is the plugin.dll path relative to the editor program.

Upon program startup the ini file will be parsed looking for the plugins listed there. It will create a SubMenu "Plugins" if it doesn't already exist. It will list each plugin in the Plugins submenu, and give it an ID number to be used for activating the named plugin.

In the editor, the Plugins submenu will be inserted to the immediate left of the Settings and Help menus on the menu bar. In this program, to the left of the Help menu. I am currently finishing up all of that code.

[jj2007]

In the programs ini file plugins will be listed under the section [Plugins]. (where else)
Due to the nature of the design would not be able to use "GetPrivateProfileString" for the obvious reason that the editor has no knowledge of what plugins might be used, a no-brainer.

Another solution is put them into a dedicated Plugins folder, and to let the editor load all DLLs and executables it finds there. No need for an ini entry, and it's a very flexible setup.

Code: [Select]

Plugins\CalcSelection.dll
Plugins\CompileBasFiles.dll
Plugins\UserPlugin.dll
Plugins\AnalyseVariableUse.dll
Plugins\RichMasmPlugin.dll
Plugins\GetComInterface.dll
Plugins\WindowInPlugin.dll
Plugins\ZipTheProject.dll

[zedd151]

Thank you for your input jj, alas the process is already underway. And I do need an ini file, to indicate the user chosen text that will appear on the menu. By the way, I thought you were going to ignore tiny projects with many teensy weensy files in them. 

[jj2007]

I do need an ini file, to indicate the user chosen text that will appear on the menu.

Source of GetComInterface.dll:

Code: [Select]

.code
ExternDef txName:BYTE
txName db "Get COM interface" ; $export  <<< info for the .def file
txDesc db "§Select the name of an interface and click here", 0
...
LoadLibrary(...)
invoke GetProcAddress, hPluginDll, Chr$("txName")

[zedd151]

There is a small problem with what you suggest, qeditor plugins don't export the function name. I am following the way that qeditor plugins are structured, hence making the editor fully compatible with qeditor plugins. The only function name exported (beside LibMain) is QePlugin for legacy plugins (old style) or PiEntryPoint for the later plugin style. That is the way hutch designed the qeditor plugin interface, which I am very familiar with as I have made over a hundred qeditor plugins over the last several years. (maybe a couple of dozen of which I had publicly posted here, the rest were special purpose plugins for my own use that would have little value for others)

[zedd151]

I hit a couple snags in converting the older menu handling functions, will have to write entirely new function for use in this editor for parsing the ini file. The older code while it worked was cobbled together and not so easy to follow plus the ini file entries there were different than what I propose here. And the sparse comments there are only very little help. But, it's Saturday... I've plenty of time. 
I only need to get my idea into clear easy to follow code.    Once the ini -> menu code is done, the rest is easy. That old code should work with only minor changes.

[zedd151]

The work on the ini-to-menu functions is going well. I created a copy of the menu and tokenized the copy (will need the original left intact). Using the tokenized strings I will Create the SubMenu. Much better than the original code. Next step will be writing the code for the SubMenu creation. That should be very easy, then append the SubMenu to the resource created menu. Eeeezy Peeezy.    It will be a work of art. I will most likely be finished with it today. (Sorry, no sneek peaks until I am ready to post the finished, working, and fully tested test piece) 

[zedd151]

I have finished the 'ini to menu' code, tested it, etc. This is a demonstration of the inserted "Plugin" SubMenu. The menu items only invoke a message box for demonstration at this point, as I have yet to rewrite the plugin interface code. More to come tomorrow. 
attachment removed. I am currently revising the ini file and menu processing code

[zedd151]

Sort of an addendum to the last post. It had occured to me that I should have the massage box display the .dll associated with the menu item. So thats what this test piece does, Display the corresponding plugin dll name according to the plugin chosen. A slight modification to the plugin path in the ini file. Added a forward slash for ease in appending to the editor path, for LoadLibrary.


Haven't yet started on the plugin interface code...
attachment removed. I am currently revising the ini file and menu processing code

[zedd151]

I'm burning the midnight oil here again... the Plugin Interface code is allllmmost completed. Making the test piece ready for the masses (or them asses?) ...     
I am using the MASM32 SDK qeditor plugins "ablockc.dll" and "blockp.dll" for the testing of the two plugin interface code pieces. ablockc.dll to test the 'legacy' QePlugIn interface code, and blockp.dll to test the 'new style' PiEntryPoint interface code. Everything up until this point is going smoothly. 

The forum is awful quiet today. 
Even Mutt & Jeff haven't been around with their usual tag team shenanigans 

[zedd151]

Tomorrow (later today, it's just after 3:00 AM here) I will be posting the test version with working plugin interface. I need a few hours SleepEx before finishing up that code, I'm too tired at the moment.

[zedd151]

After some more testing of the plugin interface this morning, I came to the realization that I have to modify it a little. I will use a case insensitive search for "[Plugins]" while parsing the ini file. So any spelling of 'plugins' will be accepted. Also, had not done enough to determine where the list of plugins in the ini file ends. In the future there may be another menu entry directly after "[Plugins]" there.
I also need a few more checks in the plugin interface. So, here I go another day working on this. 
If I released the test program as-is, I am certain some idiot will find a way purposely to make it crash. So, I'll try to make it idiot proof before posting the end result. 

Another idea came to mind, that I should process the ini file for plugins only if any of the plugins are called. This would allow having most of the plugin processing code into a single procedure, if not all(I'd have to try it first).
Upon second run of that code, test if the ini file had already been processed so we can skip it after the first run.
Nevermind the stricken out text above. If the ini file is not already processed there will be no plugin menu to select a plugin from. 
I should have rethought that idea before testing it. 
Therefore it seems necessary for more than one procedure.    whoops.

I've a few more (maybe many) details to work out before posting the test piece, so bear with me.    After that, I can then start integrating the plugin interface into the full fledged editor.

[zedd151]

The code in this test piece is not perfect. But rather than keep working on it apart from the "my editor project",  I have decided to make all the next changes or modifications from within the editor project. This will be done since it may happen that the code here, when introduced to the editor code may cause unforeseen issues.
So here is the code I have up until now. This is the last 'test' version of the plugin interface code that I will post here.
Please use the batch file when creating this program. If the ini file is not found, a default ini file will be written to disk. The default ini file has been specially prepared for this test version.

At any rate, this is what I have so far... but,,, this is not the end result or final code in the least.    Still a WIP.
Tip: The plugins used here require selecting full lines of code for modification, or "Select All". The same can be said about *most* qeditor plugins. Parental discretion advised. 
attachment removed. I am currently revising the ini file and menu processing code

[NoCforMe]

The work on the ini-to-menu functions is going well. I created a copy of the menu and tokenized the copy (will need the original left intact). Using the tokenized strings I will Create the SubMenu.

I'm curious about one thing: what do you consider "tokenization" to be? Earlier here I described extracting tokens as part of the parsing process; don't know if you read that thread or not. My usage of that term was the generally accepted one in the realm of computer science.

So what exactly do you do to "tokenize" strings? Just curious.