Hello,
Is there a way I don't know to have different files opened according to the active project in a workspace ?
For example, say I have a workspace with two projects called App1 and App2. I would like to have app1.cpp opened when App1 is active and app2.cpp + app2.h when App2 is active.
Once I was in need of the same thing but with different targets instead of projects but it wasn't possible at the time and needed implementation.
Ouch ! So, it sounds like we (knowing I'm not a C::B dev too) have a feature request here.
Please, killer C::B Team, could you implement such a thing : keep reference of opened files per project and target through two checkboxes in general settings ?
That would be nice and very useful really.
Unfortunately this is not possible and someone should implement it. The easiest way would be to make a plugin.
It would have been good if it would be possible to implement this feature with a script, but unfortunately there is no way to connect functions to events in squirrel.
At least there is no info in the documentation in the wiki about events.
Cannot the names of active files be saved in some list (maybe the project file?) and then reloaded back when the target/project is switched?
It is doable, but someone has to do it :)
In general this is a good idea, but if implemented it MUST be optional. I often read files from other projects when programming.
The main problem I have detected is that the number of opened files tends to increase rapidly as you work in Code::Blocks, and at some point you simply have to close all and start over. Perhaps it would be useful with a feature like "Close files from non-active projects". Likewise, one might consider a "close *.cpp files" or "close *.h files", or even "close abc*.cpp" etc. I think you get the idea: A plugin could be created that allowed easy closing of open workspace files based on user-defined rules. The rules could be defined more or less in a similar manner as when you create mail filters in Thunderbird. Call the plugin "TidyWorkspace" or something like that.
The idea is hereby donated ;D
Quote from: oBFusCATed on December 22, 2013, 08:57:24 PM
It is doable, but someone has to do it :)
Nice ! So, could you please add it in the TODO list, Obfuscated ? ::)
And awaiting this (nothing urgent), could you tell us where this list is saved (registry, project file, workspace, appdata) ; then, we could manage a temporary fix outside of the C::B logic...
@cacb : your idea is quite advanced, but maybe a second stage (since as Obfuscated said : "someone has to do it"), an extended one after a first "basic" plugin to just manage files sets binded with project and target.
Quote from: eranon on December 23, 2013, 11:09:35 AM
Nice ! So, could you please add it in the TODO list, Obfuscated ? ::)
No, because the TODO list is my personal TODO list and contains things that I need or want to implement. This feature is not one of them, because I don't see a use case for it in my daily use of C::B.
But you can always add a feature request at the project page on berlios.de.
Quote
And awaiting this (nothing urgent), could you tell us where this list is saved (registry, project file, workspace, appdata) ; then, we could manage a temporary fix outside of the C::B logic...
Are you asking about the open file list?
OK, it's submitted to the tracking system at http://developer.berlios.de/feature/index.php?func=detailfeature&feature_id=5716&group_id=5358
Yes, I talk about the location where the open files list is saved.
Quote from: eranon on December 23, 2013, 12:55:42 PM
OK, it's submitted to the tracking system at http://developer.berlios.de/feature/index.php?func=detailfeature&feature_id=5716&group_id=5358
Yes, I talk about the location where the open files list is saved.
It's the *.layout-file belonging to the project.
By the way, you should take into account, that opening and closing a large amount of files might take a long time.
When I first felt the need for such a feature was when I was working on a project with multiple hardware nodes with each having a separate mcu of their own. So I created different targets for each and consequently there were different 'main.c's dedicated to each and when I switched a target, I also had to locate the correct 'main.c' to edit apart from other files and it was quite error prone. So cb is a multiple target and/or multiple project ide and what's the intended way to cope with this problem (of maybe just mine)? Is there a better way to distinguish between the different files of different projects that I'm missing?
The most trvial thing to implement, as a plugin, would be a right click option in the project manager to close files that don't belong to the project.
Quote from: scarphin on December 23, 2013, 04:11:16 PM
When I first felt the need for such a feature was when I was working on a project with multiple hardware nodes with each having a separate mcu of their own. So I created different targets for each and consequently there were different 'main.c's dedicated to each and when I switched a target, I also had to locate the correct 'main.c' to edit apart from other files and it was quite error prone. So cb is a multiple target and/or multiple project ide and what's the intended way to cope with this problem (of maybe just mine)? Is there a better way to distinguish between the different files of different projects that I'm missing?
Might try virtual folders the same name as the targets to help.
Tim S.
Quote from: jens on December 23, 2013, 01:05:30 PM
It's the *.layout-file belonging to the project.
By the way, you should take into account, that opening and closing a large amount of files might take a long time.
OK, thanks, Jens ! However, I don't need to open a lot of files at the same time. I often include a test project beside my real one in a same workspace : so, in this specific context, I would like to have a different set of files opened when I'm on the real project and the one for misc tests (here, test being to take in the sense of "garbage" project where I attempt everything before to implement for real).
It's an old topic but has relevance to the patch I posted here -> https://sourceforge.net/p/codeblocks/tickets/182/ (https://sourceforge.net/p/codeblocks/tickets/182/)
It's a patch for Open Files List plugin implementing the preservation of previously opened (built-in) editor files per project/target basis. Some notes about the feature:
1- It doesn't save the splits but they can still be used.
2- Adds a View Menu item 'Preserve open editors' to enable/disable the feature. It can be activated/deactivated only when the workspace is empty because of implementation constraints.
3- Only built-in editors that belong to the current project can be preserved, others are left as is.
4- Last active editor and editor order are both preserved.
5- Open editor lists are saved in .layout file(s) for project(s), no extra files are created.
For you interest...