During my travels earlier this week, I have come up with a vehicle that I think, if implemented, would be worth it's weight in gold, and have broad enough application to where it's development by the NPP team may make 'Spock-sense' - i.e. providing a large leverage-able direct benefit to many users vs. a few (one? ;-). I am posting to throw this idea out here for consideration by Jens/Don/others.
I pose my question: Is the development of a plug-in framework where a docked-horizontal window is created, where an external application's process'/windows could exist, viable?
I'll explain. Currently, I am using NPP in it's native form, with plug-ins. I am using NPP as the front end of an ARMbasic IDE (ARMbasic is a BASIC for programming embedded ARM-based micro-controller Single Board Computers - i.e. the NXP 2103/2106-based ARMmite). I am using the ability to execute external binaries, calling compiled AutoHotKey scripts. Right now, when I click the 'Compile&Flash' command from the run menu, I pass the current source file, via the $(FULL_CURRENT_PATH) env. variable, to the compiled script. My script then takes this and passes the source file path/name to the preprocessor. The preprocessor generates a composite __temp.bas source file (or a __cmperr.tmp if errors exist). If no errors, the script then serially (via the port.dll tool) queries the target board to get some parameters, and concatenates these parameters onto the front end of the composite file and then passes the resultant __temp.bas file to the compiler which generates a pseudo-intel-hex __temp.out file (or a __cmperr.tmp file if errors). Once the compiling is done, if no errors are tossed, the resultant hex file is then flashed to the target by the script itself (again, making use of the port.dll tool). If the flashing is successful, as determined by the script, the application in the newly-flashed-target is executed.
My end goal is to get all of the functionality embedded from within the NPP environment - i.e. have a horizontal docked plug-in that has several tabs (flashing options(com port/baud/etc)|preprocessor results|composite source|compiler dialogue|compiler output|etc.).
Now, the obvious approach would be to write a plug-in that facilitates this directly. That approach makes complete sense, and frankly, if I possessed the skill sets, would be my first choice. However, the problem, as I eluded to, is that I don't possess the skill sets to code up a plug-in. It is simply not something that I feel would provide the return desired, based upon the amount of investment that I would have to make to get through the learning curve...
So, is it the group's opinion that a framework for 'housing' an external application's windows viable and easily implemented, allowing a user to then create application that could be programmed to take focus inside of this frame?
It seems that if this was facilitated, then any number of users could then write scripts in their language of choice and program the scripts to take focus inside the target frame, giving the NPP user community another tool with which to leverage NPP as the front end for their needs, and writing widgets that will work taking their control from and residing inside of the NPP frame.
Now, I understand that normal servicing of events could be problematic for events such as frame resizing, but much like what I vaguely understand with the plug-in implementation, things are passed via messages, right.?. The difference is that the messaging interface for the external tools could be through environment variables, vs. the windows messaging subsystem.
A simple example - assuming that a frame was created and the frame's vitals (position/size) were passed to the external tool, and the external tool placed a window inside of this frame (i.e. AHK allows a 'owned' window to be opened, allowing user interaction, but not steal focus from the app that has focus, and staying on top). If the frame's border was resized in NPP by the user, on the mouse-down-frame-resize event, a call to the external app could be made passing the event handle, telling the tool that the frame is being resized and to hide/destroy it's window. When the resizing event is completed, call the external app again, passing the new frame's vitals, indicating that the resizing event is completed and that the window needs to be un-hidden & repositioned/resized (or recreated) and things progress on their merry way.
There are four other events that I could see would be immediately needed:
1) frame-create - i.e. when the tool was 'opened' inside NPP
2) frame-closed - i.e. if the tool was closed by the user (or if NPP exited)
3) frame to back - i.e. if the user brought up a different tab in the horizontal dock area, and
4) frame to top - i.e. if the user clicked on the tool's tab bringing it to the front.
Obviously, as the framework matures, maybe other functionality to further integrate the external tools with NPP could be created...
Implementing this would seem to be a means to allow a greatly broadened use of NPP, at seemingly very low cost of implementation.?. Many are using NPP. Many are using AHK. Being able to wed the two, as far as the UI goes, would seem to be a great enhancement for both tools...
OK, I have blabbed on enough. Please review and advise if any of this makes sense.
Thanks so much, in advance, for considering what I present.
-t
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey folks. OK, I am progressing along my chosen path.
I basically hacked plugintemplate.dll with a resource editor and changed the title of the plugin, changed the icons, deleted the edit control, and renamed it.
This provided a blank named frame/window that I can then look for in and AHK script and populate with a borderless window to create my IDE's GUI.
I have progressed through that phase of the efforts, and I am not into the next phase - giving the new GUI's controls code, to act on. One of my buttons is "Load NPP File". This allows the user to make use of the file currently being edited in NPPs active editor tab.
I would like for my AHK script to force NPP to have the file to be saved before the flashing event, so that the user doesn't think that they have saved it and will actually be flashing the old instance on the HDD.
My question is this: Can the NPP messaging (detailed here: http://notepad-plus.sourceforge.net/uk/plugins-HOWTO.php\) be utilized by outside process' to force NPP to act - i.e. in this case to save the current file being edit with the NPPM_SAVECURRENTFILE command? Please review and advise if known. Thank you!
-t
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What you need is a plugin which can do several tasks sequentially, and push the results of each executed task as the value of environment variable for next execution, right?
You can use batch file to get the returned value or detect the generated file in order to form the environment variable, then calling your executable file.
Use the existing plugin NppExec to execute several batch files. I believe NppExec can do it well.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LOL - OK. I guess I over-complicated things... :-)
Quite simply (I think), I want a docking form inside of NPP that I can then force an external executable's window to exist in. Kind of like launching a 2nd instance of a browser inside of an I-Frame (I think).
That way, I can have all of my IDE's functionality inside of a NPP form, vs. having to bounce from app to app to keep track of things.
I'd like the form to be a horizontal one, when docked, like the console.
Obviously, if I am using a resizable/dockable/movable form inside of NPP, the application 'residing' therein (making use of the form's space) needs to know when it needs to resize itself to match the forms new size/location, if the user changes it, closes it, etc.
^^^ This is where I was talking about using the passage of environment variables to convey to the app residing therein that things have changed and that it needs to react...
Hopefully that is a bit clearer? I was over-tired when I drafted the above, and I tend to get wordy (a lot) when I get tired...
Please let me know. Thanks!
-t
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if I understand you correctly you would like to have an plugin that handles external programs. For example you can define some application executables like calc.exe and cmd.exe. When you start those applications there exist normaly a dialog. You would like to have a plugin that "snapps" these dialog handles and displays them as a docked view, at best without the border.
Features:
- You can set a list of some applications that started on startup of Notepad++. These apps will be automatic docked.
- All applications will be closed when Notepad++ is going to close.
- I think your "back" and "top" means nothing more than hide and view them in dependency of active or inactive state.
Best Regards
Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, we are getting closer to understanding the intentions:
> if I understand you correctly you would like to have an plugin that
> handles external programs. For example you can define some application
> executables like calc.exe and cmd.exe. When you start those applications
> there exist normaly a dialog. You would like to have a plugin that "snapps"
> these dialog handles and displays them as a docked view, at best without
> the border.
Yes, that is effectively what I am looking for.
> Features:
> - You can set a list of some applications that started on startup of
> Notepad++. These apps will be automatic docked.
Yes, intended. If feasible, I'd like to support resizing the docked form, and having environment variables that reflect the state (active or inactive), size, and location of the form, so that the docked application can adjust it's dialog size according to the user's NPP preferences.
> - All applications will be closed when Notepad++ is going to close.
Yes. Acceptable. And also hide the external apps dialogue when the docked form is closed (or close the external app as well vs. just hiding it.?.)
> - I think your "back" and "top" means nothing more than hide and view them
> in dependency of active or inactive state.
Yes ... In NPP, currently, when the Console and the FTP plugins are opened, at the bottom, there are two folder tabs that the user can select to either display the console dialogue, or the FTP Messages. I am thinking that this new plugin could be an additional tab in that docked section, when selected, displays the dialogue from the external app (bringing the external apps dialogue to the front or "Top"), and when another tab is selected, bring that tab's dialogue to the top, and send the previously selected dialogue to the back (de-activate it/send it to the bottom/hide it/etc...) - just like it is working now with the Console/FTP Messages.
I am sorry that I can't articulate it that well...
Does this seem to be too user specific, or does it make sense that this could have broader applications, allowing more functionality for other users?
Thanks.
-t
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Capturing console output is a non-issue since plenty of tutorials exist for doing this exercise. Communicating with another application requires some API wizardry. Docking a window to another application would require manipulating the target window's main form attributes. I don't know if this will help but there is a free tool called WinDowse ( http://www.greatis.com/delphicb/windowse/ ) that displays the attributes of a target window.
Are you trying to develop an HTML viewer or dock an open web browser to NPP?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Negative, I am trying to dock the window from a compiled AutoHotKey script that will act as my tool chain for an embedded processor. I used the i-frame as a reference, only because of it's familiarity. However, your idea about having an embedded HTML display, for use when NPP is being used as an HTML editor, seems to make sense, and rings true with my overall intention with the idea for the plugin...
Currently my scripts gets passed the filename for the currently edited source-code file. It kicks off the preprocessor on the saved source file, and the preprocessor's output file is then fed to the compiler for hex file generation. The hex file is then flashed onto the target SBC (Single Board Computer) directly by the script, via the use of the Port.DLL tool that provides serial port connectivity. Right now, I have a 2nd window opening and all activity taking place therein. I'd like to have the 2nd window be integrated into a dockable form within NPP.
I think that the development of a plugin that would facilitate this would ultimately open up NPP to a lot of other additional uses. There are a plethora of scripting languages out there, and for those that facilitate GUI generation/User Interaction, it stands to reason that many could potentially benefit from being able to programmatically have their GUI integrated onto a NPP form.
Maybe I am on Dra-ughs, maybe not. The idea seems to be promising, at least to this ignorant person...
Thanks for catching on and broadening the idea's applicability.
Take care.
-t
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are scripting languages that can be embedded in a project. Remobjects has Pascal Script. If the code processing procedure produces all output in a console then scripting it with a batch file should be easier than writing a plugin. What could be interesting if not useful would be a command shell with syntax highlighting similar to 4DOS and 4NT from back in the day.
If the process is another Windows program like calc, notepad, etc. then a simple plugin that makes shell execute API calls from button clicks should be fairly easy to do. The launched program would not be docked but the plugin that launches it could be docked.
I hope this is helping.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey guys & gals.
During my travels earlier this week, I have come up with a vehicle that I think, if implemented, would be worth it's weight in gold, and have broad enough application to where it's development by the NPP team may make 'Spock-sense' - i.e. providing a large leverage-able direct benefit to many users vs. a few (one? ;-). I am posting to throw this idea out here for consideration by Jens/Don/others.
I pose my question: Is the development of a plug-in framework where a docked-horizontal window is created, where an external application's process'/windows could exist, viable?
I'll explain. Currently, I am using NPP in it's native form, with plug-ins. I am using NPP as the front end of an ARMbasic IDE (ARMbasic is a BASIC for programming embedded ARM-based micro-controller Single Board Computers - i.e. the NXP 2103/2106-based ARMmite). I am using the ability to execute external binaries, calling compiled AutoHotKey scripts. Right now, when I click the 'Compile&Flash' command from the run menu, I pass the current source file, via the $(FULL_CURRENT_PATH) env. variable, to the compiled script. My script then takes this and passes the source file path/name to the preprocessor. The preprocessor generates a composite __temp.bas source file (or a __cmperr.tmp if errors exist). If no errors, the script then serially (via the port.dll tool) queries the target board to get some parameters, and concatenates these parameters onto the front end of the composite file and then passes the resultant __temp.bas file to the compiler which generates a pseudo-intel-hex __temp.out file (or a __cmperr.tmp file if errors). Once the compiling is done, if no errors are tossed, the resultant hex file is then flashed to the target by the script itself (again, making use of the port.dll tool). If the flashing is successful, as determined by the script, the application in the newly-flashed-target is executed.
My end goal is to get all of the functionality embedded from within the NPP environment - i.e. have a horizontal docked plug-in that has several tabs (flashing options(com port/baud/etc)|preprocessor results|composite source|compiler dialogue|compiler output|etc.).
Now, the obvious approach would be to write a plug-in that facilitates this directly. That approach makes complete sense, and frankly, if I possessed the skill sets, would be my first choice. However, the problem, as I eluded to, is that I don't possess the skill sets to code up a plug-in. It is simply not something that I feel would provide the return desired, based upon the amount of investment that I would have to make to get through the learning curve...
So, is it the group's opinion that a framework for 'housing' an external application's windows viable and easily implemented, allowing a user to then create application that could be programmed to take focus inside of this frame?
It seems that if this was facilitated, then any number of users could then write scripts in their language of choice and program the scripts to take focus inside the target frame, giving the NPP user community another tool with which to leverage NPP as the front end for their needs, and writing widgets that will work taking their control from and residing inside of the NPP frame.
Now, I understand that normal servicing of events could be problematic for events such as frame resizing, but much like what I vaguely understand with the plug-in implementation, things are passed via messages, right.?. The difference is that the messaging interface for the external tools could be through environment variables, vs. the windows messaging subsystem.
A simple example - assuming that a frame was created and the frame's vitals (position/size) were passed to the external tool, and the external tool placed a window inside of this frame (i.e. AHK allows a 'owned' window to be opened, allowing user interaction, but not steal focus from the app that has focus, and staying on top). If the frame's border was resized in NPP by the user, on the mouse-down-frame-resize event, a call to the external app could be made passing the event handle, telling the tool that the frame is being resized and to hide/destroy it's window. When the resizing event is completed, call the external app again, passing the new frame's vitals, indicating that the resizing event is completed and that the window needs to be un-hidden & repositioned/resized (or recreated) and things progress on their merry way.
There are four other events that I could see would be immediately needed:
1) frame-create - i.e. when the tool was 'opened' inside NPP
2) frame-closed - i.e. if the tool was closed by the user (or if NPP exited)
3) frame to back - i.e. if the user brought up a different tab in the horizontal dock area, and
4) frame to top - i.e. if the user clicked on the tool's tab bringing it to the front.
Obviously, as the framework matures, maybe other functionality to further integrate the external tools with NPP could be created...
Implementing this would seem to be a means to allow a greatly broadened use of NPP, at seemingly very low cost of implementation.?. Many are using NPP. Many are using AHK. Being able to wed the two, as far as the UI goes, would seem to be a great enhancement for both tools...
OK, I have blabbed on enough. Please review and advise if any of this makes sense.
Thanks so much, in advance, for considering what I present.
-t
Hey folks. OK, I am progressing along my chosen path.
I basically hacked plugintemplate.dll with a resource editor and changed the title of the plugin, changed the icons, deleted the edit control, and renamed it.
This provided a blank named frame/window that I can then look for in and AHK script and populate with a borderless window to create my IDE's GUI.
I have progressed through that phase of the efforts, and I am not into the next phase - giving the new GUI's controls code, to act on. One of my buttons is "Load NPP File". This allows the user to make use of the file currently being edited in NPPs active editor tab.
I would like for my AHK script to force NPP to have the file to be saved before the flashing event, so that the user doesn't think that they have saved it and will actually be flashing the old instance on the HDD.
My question is this: Can the NPP messaging (detailed here: http://notepad-plus.sourceforge.net/uk/plugins-HOWTO.php\) be utilized by outside process' to force NPP to act - i.e. in this case to save the current file being edit with the NPPM_SAVECURRENTFILE command? Please review and advise if known. Thank you!
-t
I have no idea what you said, but good luck anyway.
What you need is a plugin which can do several tasks sequentially, and push the results of each executed task as the value of environment variable for next execution, right?
You can use batch file to get the returned value or detect the generated file in order to form the environment variable, then calling your executable file.
Use the existing plugin NppExec to execute several batch files. I believe NppExec can do it well.
Don
LOL - OK. I guess I over-complicated things... :-)
Quite simply (I think), I want a docking form inside of NPP that I can then force an external executable's window to exist in. Kind of like launching a 2nd instance of a browser inside of an I-Frame (I think).
That way, I can have all of my IDE's functionality inside of a NPP form, vs. having to bounce from app to app to keep track of things.
I'd like the form to be a horizontal one, when docked, like the console.
Obviously, if I am using a resizable/dockable/movable form inside of NPP, the application 'residing' therein (making use of the form's space) needs to know when it needs to resize itself to match the forms new size/location, if the user changes it, closes it, etc.
^^^ This is where I was talking about using the passage of environment variables to convey to the app residing therein that things have changed and that it needs to react...
Hopefully that is a bit clearer? I was over-tired when I drafted the above, and I tend to get wordy (a lot) when I get tired...
Please let me know. Thanks!
-t
Hello,
if I understand you correctly you would like to have an plugin that handles external programs. For example you can define some application executables like calc.exe and cmd.exe. When you start those applications there exist normaly a dialog. You would like to have a plugin that "snapps" these dialog handles and displays them as a docked view, at best without the border.
Features:
- You can set a list of some applications that started on startup of Notepad++. These apps will be automatic docked.
- All applications will be closed when Notepad++ is going to close.
- I think your "back" and "top" means nothing more than hide and view them in dependency of active or inactive state.
Best Regards
Jens
Good morning, Jens (& Others)!
Yes, we are getting closer to understanding the intentions:
> if I understand you correctly you would like to have an plugin that
> handles external programs. For example you can define some application
> executables like calc.exe and cmd.exe. When you start those applications
> there exist normaly a dialog. You would like to have a plugin that "snapps"
> these dialog handles and displays them as a docked view, at best without
> the border.
Yes, that is effectively what I am looking for.
> Features:
> - You can set a list of some applications that started on startup of
> Notepad++. These apps will be automatic docked.
Yes, intended. If feasible, I'd like to support resizing the docked form, and having environment variables that reflect the state (active or inactive), size, and location of the form, so that the docked application can adjust it's dialog size according to the user's NPP preferences.
> - All applications will be closed when Notepad++ is going to close.
Yes. Acceptable. And also hide the external apps dialogue when the docked form is closed (or close the external app as well vs. just hiding it.?.)
> - I think your "back" and "top" means nothing more than hide and view them
> in dependency of active or inactive state.
Yes ... In NPP, currently, when the Console and the FTP plugins are opened, at the bottom, there are two folder tabs that the user can select to either display the console dialogue, or the FTP Messages. I am thinking that this new plugin could be an additional tab in that docked section, when selected, displays the dialogue from the external app (bringing the external apps dialogue to the front or "Top"), and when another tab is selected, bring that tab's dialogue to the top, and send the previously selected dialogue to the back (de-activate it/send it to the bottom/hide it/etc...) - just like it is working now with the Console/FTP Messages.
I am sorry that I can't articulate it that well...
Does this seem to be too user specific, or does it make sense that this could have broader applications, allowing more functionality for other users?
Thanks.
-t
Capturing console output is a non-issue since plenty of tutorials exist for doing this exercise. Communicating with another application requires some API wizardry. Docking a window to another application would require manipulating the target window's main form attributes. I don't know if this will help but there is a free tool called WinDowse ( http://www.greatis.com/delphicb/windowse/ ) that displays the attributes of a target window.
Are you trying to develop an HTML viewer or dock an open web browser to NPP?
Negative, I am trying to dock the window from a compiled AutoHotKey script that will act as my tool chain for an embedded processor. I used the i-frame as a reference, only because of it's familiarity. However, your idea about having an embedded HTML display, for use when NPP is being used as an HTML editor, seems to make sense, and rings true with my overall intention with the idea for the plugin...
Currently my scripts gets passed the filename for the currently edited source-code file. It kicks off the preprocessor on the saved source file, and the preprocessor's output file is then fed to the compiler for hex file generation. The hex file is then flashed onto the target SBC (Single Board Computer) directly by the script, via the use of the Port.DLL tool that provides serial port connectivity. Right now, I have a 2nd window opening and all activity taking place therein. I'd like to have the 2nd window be integrated into a dockable form within NPP.
I think that the development of a plugin that would facilitate this would ultimately open up NPP to a lot of other additional uses. There are a plethora of scripting languages out there, and for those that facilitate GUI generation/User Interaction, it stands to reason that many could potentially benefit from being able to programmatically have their GUI integrated onto a NPP form.
Maybe I am on Dra-ughs, maybe not. The idea seems to be promising, at least to this ignorant person...
Thanks for catching on and broadening the idea's applicability.
Take care.
-t
There are scripting languages that can be embedded in a project. Remobjects has Pascal Script. If the code processing procedure produces all output in a console then scripting it with a batch file should be easier than writing a plugin. What could be interesting if not useful would be a command shell with syntax highlighting similar to 4DOS and 4NT from back in the day.
If the process is another Windows program like calc, notepad, etc. then a simple plugin that makes shell execute API calls from button clicks should be fairly easy to do. The launched program would not be docked but the plugin that launches it could be docked.
I hope this is helping.