VisualPelle?

[frankie]

Thanks Timo for your last revision of message generator (http://forum.pellesc.de/index.php?topic=2486.0),
This perfectly fit what is required for use in "VisualPelles" addin 
The main problem anyway is to hack the properties popup menu in resource editor.
I can't find a way around for now.
If we can get into it we can trigger the message cracker than use it to add message handling, jump to the handler source, etc.
Pelle could give a big help supplying an access in the addin SDK, what we need as parameters is the current dialog ID and the current control.

[CommonTater]

Thanks Timo,
This perfectly fit what is required for use in "VisualPelles" addin 
The main problem anyway is to hack the properties popup menu in resource editor.
I can't find a way around for now.
If we can get into it we can trigger the message cracker than use it to add message handling, jump to the handler source, etc.
Pelle could give a big help supplying an access in the addin SDK, what we need as parameters is the current dialog ID and the current control.

I don't know if it's any help... but you could take a look at my article on subclassing the MDI windows... might be something from that you can modify/use ... I know it works on edit windows, not sure about the resource editor.

Ideally, it would be best if Pelle redid the addin API to allow us access to more menus and even to replace some of the dialogs (Compiler settings, would be one I'd pick.)
 

[frankie]

Tater,
I just had a look to available addin macros, and probably found a strategy. Unfortunately it will not be straightforward as to right click on a control in the IDE dialog editor.
The procedure could be the following:
- While a resource window or a dialog window is open press the visual editor button that start the routine.
- Get the active document
- Check if resource type, if not abort
- Enumerate resources in the window
- If the window is a resource window with more than one dialog popup a menu to choose which one you want edit, if it is a dialog window get it and go on
- Retrieve the selected binary resource
- Explore the binary resource to enumerate controls and put them in a table
- Create an indirect dialog using the binary resource and intercept the dialog messages
- When a control is clicked start the visual handler routine.
The handler routine will:
- Get the control type
- Check in the project visual DB if an handler was already created for this control or there is any name duplicate, etc, and dignostic
- Build a list of messages that could apply for that type of control
- Using a modified version of Timo's messagecracker display the list in a drop down control
- The user selects the message and the file where to create the handler
- Close the dialog and jump to the source file at beginning of handler version

This is just a start.
What are your comments?
Timo what do you think?

[CommonTater]

This is where I was thinking that subclassing might be an answer...
The IDE opens dialog windows with the name of the dialog in the tab.  It occured to me that if you could figure out how to subclass the dialog editor you might be able to gain suffient access to accurately locate the dialog prototype in the .rc file and perhaps open your own floating list (like the tools list) to select functions from.

You would need to test the AddIn's GetActiveDocument which gives you the window handle... then you can try the GetDocumentInfo macro to fetch the name of the dialog.  I've not played with this in respect of Dialogs so it needs to be tested.

But once you have the window handle you can probably create/open a source file with the dialog's name and with a toolbar button you could likely add a button for "edit message handler"... then automate the process of updating a switch statement after the fashion I use.  (Most dialogs don't handle a lot of messages, so this might not be as painful as it sounds)

The overall outcome (if you can get at the information) could be very like a visual tool but done in the C way in that you could open the source file, scan it to create the list then locate the message handler automagically from the list when a user clicks... perhaps even eliminating the need for a database file.
 
(FWIW... The hardest thing I do when programming is finding the easiest way to do things )

[frankie]

Yes Tater,
my first approach was this more or less, but to locate dialog in the RC file to create the dialog and visually edit it requires an on the fly compiler for resources. I almost wrote one, but at the end a gave up because it becomes a huge job.
Subclassing the window anyway makes very difficult to intercept the popup menu of dialog editing, so if we have to create the dialog anyway what I propose should be easier.
About the DB the main scope of this file is to keep memory of what was created and deployed, analyzing the source whithout any clear info could be a nightmare if the person that created the code has a very peculiar idea of coding style...  .
To avoid big problems with code in header files, bad prototypes and God knows what else a deviated human mind can imagine, I think it's better that we define the code layout, at least on first release 
Don't you?
I will try to create a very basic code and post it, then I hope we start with serious coding together 

PS: I have split and moved the topic to don't inflactionate Timo topic.

[frankie]

Here is my base code for the project.
Yes it is a little bit messed up  , but it's really a quick&dirty job  .
I have used Timo project as base.
The precompiled dll is for 32bits (I don't have 64 bits available), if you have a 64 bits version recompile it before to copy dll in addins directories.
To make it work copy the messages DB (wmsgs.db3) in the root directory of your pellesc installation.
What's next?
Using the dialog procedure of the dialog under test intercept selections and for each control show popup menu to select message to insert.
Build message procedure.
Etc.
My next step will be decompilation of resource to list controls and ID in the dialog.
Who want partecipate for the other parts? 

P.S. Some dialogs are not showed . I'll investigate

[TimoVJL]

Thank's Frankie.

That wmsgs.db3 was not VACUUMed, so new version attached.

Where should that file placed ?
- PellesC dir
- PellesC\bin with  ADDIN_FOLDER_BIN ?
- PellesC\bin\addin with ADDIN_FOLDER_ADDINS  ?

Or this way to folder where poide started ?

Code: [Select]

char szFile[MAX_PATH];
int nLen = SearchPathA(NULL, ".", NULL, sizeof(szFile), szFile, NULL);
strcat(&szFile[nLen], "\\wmsgs.db3");
sqlite3_open(szFile, &db3);

[frankie]

Timo, the best place should be in the addin directory together with the dll (easier to install). For the use with the visual code we should add a linking table to select messages that are valid for each type of control, so we will show only those that are legal for the current control.
Did you had a look to my code?
I can't understand what are these 32 bytes at beginning of binary resource got from addin. Help says that the resource data is in binary DIALOG or DIALOGEX template, but looking at the resource in the dll (using PEView) that lines are not there, For this reason I moved the pointer 32 bytes ahead.
Anyway some dialogs are not showed, I'm investigating if this is a problem with handling of WM_INITDIALOG or something about the 32 bytes, maybe a required class or God knows what  .
Do you have any idea about?

[CommonTater]

Hi guys... not to be a wet blanket, but I may not be able to give this project my fair share of attention for a while.  There's been an issue in the family and I need to direct my attention to that.  You can and should continue on without waiting for me... I'll try and catch up when I can...

[frankie]

Hi Tater,
no problem, only I hope is nothing serious. I also have a lot of work to do and could not spend much time rigt now.
Anyway nobody urge us 

The good news is that I understood why some dialogs are not shown, it is because they have a dialog class specified or a menu. This could be solved modifying the binary template on the fly removing the reference to classes and menus (also the resource editor remove menus for the dialog test).
Anyway still can't figure out what are that 32 bytes at beginning of binary resource 
I would be very glad if Pelle could explain.

[CommonTater]

Hi Tater,
no problem, only I hope is nothing serious. I also have a lot of work to do and could not spend much time rigt now.

Nope nothing too serious... just making demands on my time. 

Get back to you all when I can....

[TimoVJL]

Some fixes:
- wmsgs.db3 to AddIns-folder
- message was missing from case-clause
- 32/64 workspace

[frankie]

Thanks Timo,
Good job.

[TimoVJL]

Anyway still can't figure out what are that 32 bytes at beginning of binary resource 

RESOURCEHEADER ?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms648027(v=vs.85).aspx

[frankie]

Yes Timo you are right.
The value returned from the addin resource macros are in '.res' format so they are prefixed by a RESOURCEHEADER, while the BoxDialogIndirect function doesn't require it.
I'll fix the code skipping the header size.