Index
> IDE Development > Visual resource (dialog) editor for FASM - preliminary.Goto page Previous 1, 2 |
| Author |
|
|
JohnFound 04 Jul 2003, 09:15
Hi Tommy.
I think I understood you before and I am agree with you - this is the exact way to make plugin system. It will be usefull as method for fast extending of the IDE with different tools. But project manager, resource editor, source level library system and source level debugger needs very close binding between each other, so, I think they must be in one application. BTW: I think that this IDE must have ability to compile sources directly from memory, not only from files. |
|||
04 Jul 2003, 09:15 |
|
|
Tommy 04 Jul 2003, 09:43
JohnFound wrote: BTW: I think that this IDE must have ability to compile sources directly from memory, not only from files. Yes, I agree!! 
Actually I agree in everything you said! 
Regards, Tommy |
|||
|
04 Jul 2003, 09:43 |
|
|
scientica 04 Jul 2003, 10:40
JohnFound wrote: Of course, to have Plug-in ability in FASMW is good. But to build whole IDE based only on Plugins, that is not very good IMHO. I must say that the the text editor is an essential part of the fasmw, after the compiler core it's the most importart part of fasmw, so that should be in the main exe. But plug-ins are add ons, it's not good to build them in, because then you'll endu having to recompile your fasmw exe every time you add/remove a plug in, and that can cause problems. And when having dll plug-ins they can be used with other editors, presumed they use the same (plug-in) interface. Plug-ins are small extensions, or things such as resource editors. As you say Tommy, project manager, resource editor, source level library system and source level debugger should be implented in to the GUI, as modules (either DLLs or in an own code section), I can partially agree, however I think a resource editor is more suitable as plugin than core component, since one might want more than one resrouce editor (one editor might bee good on forms another on string tables, cursors and such). However debugers, project managers are such things that more or less requires core intergration, especially teh debugger (since there mgith be support for modifying code at runtime, and then jit-compiling of "one liners" (sinlge instruction line) should utilize the core compiler (so that labels and such can be used). Isn't that what happens? (the file is in memory as it's assembled, it's not read from disk, however it's the files are saved before compile (what about making that customizable, one more line in the ini?) ) _________________ ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn |
|||
|
04 Jul 2003, 10:40 |
|
|
Tomasz Grysztar 09 Jul 2003, 20:30
I've done some work on the FASMW source to make it easier to add plug-in support in future - also for this purpose I will start the separate versioning for the FASMW interface (so each executable will have two version numbers - one for the core and one for the interface), so the plug-ins will be able to detect on which version they are applied.
The way I'm planning to implement plug-ins is without an exports from FASMW, the IDE will just initialize each plug-in by calling some initialization function from DLL, providing the version of interface and the handle of FASMW window. All operations will be done by sending appropriate messages to the FASMW window. |
|||
|
09 Jul 2003, 20:30 |
|
|
comrade 09 Jul 2003, 23:14
I hope this doesn't increase loading time. Currently FASMW loads as fast as Notepad, and I really appreciate that. That is one of the most important reasons I use FASMW IDE as opposed to EditPro or UltraEdit. And of course FASMW is nicer.
Last edited by comrade on 10 Jul 2003, 00:01; edited 1 time in total |
|||
|
09 Jul 2003, 23:14 |
|
|
Tomasz Grysztar 09 Jul 2003, 23:22
The loading time won't be noticeably increased unless you're using some huge and slowly initializing plug-in. And that also the greates advantage of plug-ins that you'll be able to enable only the ones that you really need (or none at all) to keep the loading as quick as possible.
|
|||
|
09 Jul 2003, 23:22 |
|
|
Daemon 10 Jul 2003, 11:03
The main idea of adding plugins into fasm is:
1. Use INI file to save plugin information; Code: [Environment] Include = D:\prog\fasm\include [Plugins] flink.dll fresh.dll fimport.dll 2. DLL code must contain procedures such as 'Initialize', 'Shutdown' and 'Run' with fasm's main window [hwnd] parameter (and maybe some more too...). On Init procedure we'll load & append DLL's menus to main FASMW menu (& then unload in Shtdn proc). Within the 'Run' proc we can open a window (dialog) for some data to input. Menu Procedures (from MS): Code: HMENU GetMenu(HWND hWnd); //<- FASMW's mainhWnd! BOOL AppendMenu(HMENU hMenu, UINT uFlags, UINT_PTR uIDNewItem, LPCTSTR lpNewItem); You can find more API functions at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/menus.asp. Happy FASM'ing,
|
|||
|
10 Jul 2003, 11:03 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|