Poide Improvements (wish list)

[CommonTater]

Of late I've been spending quite a bit of time building AddIns for POIDE.  In fact I think the IDE is good enough that it could (and maybe should) be expanded for more general purpose use in programming.  There is no other IDE with all of the features of POIDE... and Pelle I am extremely grateful for all your work and time on this!

There are a couple of changes that hopefully aren't too big, that would make all the difference in the world...

1) Adding files to projects.
It would be really nice if we could add "extra" files to projects. Often I will have pdf and html reference files related to the work I'm doing and it would be really nice if we could stuff them in an "Extra" category to open on a click or double click.

2) Adding new file types via AddIns...
The present AddIn_AddFileType macro is one of POIDE's best tools. However the implementation could be just a tad better.  The current macro assumes we are going to build every file type we add and this isn't always the case.  For example in my latest AddIn (C++ on POIDE) I was unable to get it to add .h or .hpp files to the project.  I would get the dreaded "Can't determine file type from extension" message, or it would try to build the file!

I don't know the internals of POIDE so I don't know how much work this is, but I would really like to see a change in the struct used by the AddIn_AddFileType macro.

Code: [Select]

typedef struct tagADDIN_ADD_FILE_TYPE_W {  /* (5.00) */
UINT cbSize;
DWORD DisplayAs;            <--- select project tab for new file type...    
LPCWSTR pszDescription;
LPCWSTR pszExtension;
USHORT (CALLBACK *pfnParser)(USHORT usCookie, LPCWSTR pszText, int cchText, ADDIN_PARSE_POINT aPoints[], PINT pcPoints);
DWORD reserved;
LPCWSTR pszShells;
} ADDIN_ADD_FILE_TYPE_W, *PADDIN_ADD_FILE_TYPE_W;
 

DisplayAs, should let us set a location for the file ... Source, Include, Resource, Extra...  So that when we add a file type to the IDE we can specify where it should be added in the project pane.  For example, with the C++ AddIn, I've added the HPP file type, to get C++ syntax highlighting of header files, but was unable to add them to the project.  This would provide a much needed way to work around that problem.  

Also if pszShells is NULL it should not try to build the file.


3) Workspace Files
POIDE should provide an internal dialog to let us view, edit, move and copy Workspace files.  It would be a huge convenience to place workspace files below the tree where the project files are.  The WsEdit addin allows this, with some limitations and I do believe it would be better as an internal dialog where it could load the current workspace on launch.

4) Replaceable dialogs
I'm thinking mainly of the project options dialog although there might be others.  Being able to replace the project options dialog with one of our own, from an AddIn, would be extremely helpful in integrating new compilers in to the IDE.  I'm not sure how you'd set that up though.  Perhaps through callback functions that block certain dialogs if they return FALSE, so we can display our own.


Love your work Pelle... and thanks again for such a fine product!

[MirekCZ]

or 5) window ide frame configuration.For instance left rectangle from top to down only editor (with ability horizontal splitbar), left files tree (as usual), left down compilation status and so on. Splitting line is very usefull and many rows on my monitor too.

btw: Pelle, great job with your C !!! (I am little bit older programmer. My evolution stop was BorlandC2.0 timeline, but your package brought me new motivation to be still good C programmer today. THNX

[migf1]

An old topic, but I figure there's no need for a new one.

I would very much like to have poIDE tabs closing by double-clicking on them. Perhaps as an addition or an alternative to the current right-click behavior.

Thanks.

PS. Re-locating (moving) tabs inside the tab-bar would be nice too, but I think this one needs more work.

[Pelle]

1) Adding files to projects.
It would be really nice if we could add "extra" files to projects. Often I will have pdf and html reference files related to the work I'm doing and it would be really nice if we could stuff them in an "Extra" category to open on a click or double click.

You can, but they must have a ".txt" extension. Other extensions should probably be configurable, but I rather spend my time on something more useful.

2) Adding new file types via AddIns...
The present AddIn_AddFileType macro is one of POIDE's best tools. However the implementation could be just a tad better.  The current macro assumes we are going to build every file type we add and this isn't always the case.  For example in my latest AddIn (C++ on POIDE) I was unable to get it to add .h or .hpp files to the project.  I would get the dreaded "Can't determine file type from extension" message, or it would try to build the file!

Projects are basically for building things, so...

DisplayAs, should let us set a location for the file ... Source, Include, Resource, Extra...  So that when we add a file type to the IDE we can specify where it should be added in the project pane.  For example, with the C++ AddIn, I've added the HPP file type, to get C++ syntax highlighting of header files, but was unable to add them to the project.  This would provide a much needed way to work around that problem. 

I can't see how this would add anything useful.

Also if pszShells is NULL it should not try to build the file.

It doesn't, AFAIK.

3) Workspace Files
POIDE should provide an internal dialog to let us view, edit, move and copy Workspace files.  It would be a huge convenience to place workspace files below the tree where the project files are.  The WsEdit addin allows this, with some limitations and I do believe it would be better as an internal dialog where it could load the current workspace on launch.

The workspace file is created where the first project file is located. This works fine for me. I really, really, don't want tp specify a location for the workspace file too.

4) Replaceable dialogs
I'm thinking mainly of the project options dialog although there might be others.  Being able to replace the project options dialog with one of our own, from an AddIn, would be extremely helpful in integrating new compilers in to the IDE.  I'm not sure how you'd set that up though.  Perhaps through callback functions that block certain dialogs if they return FALSE, so we can display our own.

I don't want to support other compilers too easily in the IDE. You should be able to handle some things through the add-in interface, but then you should also be aware that you are "on your own" in getting in working properly. It's possible that the add-in interface should be extended somehow, but I can't see that your current suggestions are very useful. Sorry.

[Pelle]

I would very much like to have poIDE tabs closing by double-clicking on them. Perhaps as an addition or an alternative to the current right-click behavior.

It depends on what the standard Windows Tab-control can provide in terms of events. I havn't checked. I don't want to start subclassing, or whatever, just to get this behaviour.

PS. Re-locating (moving) tabs inside the tab-bar would be nice too, but I think this one needs more work.

Same here, I think.

[Pelle]

or 5) window ide frame configuration.For instance left rectangle from top to down only editor (with ability horizontal splitbar), left files tree (as usual), left down compilation status and so on. Splitting line is very usefull and many rows on my monitor too.

Not sure I understand everything you say, but you can use "Window" -> "New window" to get a second (or third, ...) window referring to the same text buffer, and then use "Window" -> "Tile xxx" to arrange the windows so that you can look at two (or three, ...) different locations in the same file.
This is somewhat old style, but it works for now...

[migf1]

I would very much like to have poIDE tabs closing by double-clicking on them. Perhaps as an addition or an alternative to the current right-click behavior.

It depends on what the standard Windows Tab-control can provide in terms of events. I havn't checked. I don't want to start subclassing, or whatever, just to get this behaviour.

Fair enough (I think it does, but I'm not sure either).

[CommonTater]

Fair enough (I think it does, but I'm not sure either).

It does send the standard Common Controls NM_DBLCLK notification, but it's not specific to one of the tabs it can be anywhere "within the control".  From there find the currently selected tab and close it... But there may be places where that would backfire, such as in the registry editor where you often double click to get an item's properties.

[migf1]

Fair enough (I think it does, but I'm not sure either).

It does send the standard Common Controls NM_DBLCLK notification, but it's not specific to one of the tabs it can be anywhere "within the control".  From there find the currently selected tab and close it... But there may be places where that would backfire, such as in the registry editor where you often double click to get an item's properties.

It sounds like a hassle. But since the code seems to already calculate the clicked tab when an NM_RCLICK notification is handled, it sounds trivial to do the same when an NM_DBCLICK notification is catched. I just had a quick look at msdn and those 2 notifications seem to return the same kind of info, via (LPNMHDR) lParam (http://msdn.microsoft.com/en-us/library/bb760559.aspx and http://msdn.microsoft.com/en-us/library/bb760558%28VS.85%29.aspx).
 
PS. I lost you a bit about the registry editor, does the documents' tab-bar share the same callback function with the registry editor? Or to put it in other words, do they share the same tab-control? If so, then it's indeed a problem.

[CommonTater]

PS. I lost you a bit about the registry editor, does the documents' tab-bar share the same callback function with the registry editor? Or to put it in other words, do they share the same tab-control? If so, then it's indeed a problem.

That's why I said "may" instead of "are"... I don't know.  The only person who does is Pelle...

If you want to see how tab controls are normally handled, take a look in the setup.c file from my C++ AddIn... At the bottom of the page is (what I think is) the best way to do it and yes, they all share the same tab control...
 
PS. Did I mention how much I hate tab controls... It's like    and    working with them.
 
 

[Stefan Pendl]

Currently most applications I am using are closing tabs through the middle mouse button click, so this would be more of a regular action.