Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: eranon on December 22, 2013, 02:03:50 pm
-
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
-
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.
-
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.
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.
-
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.
-
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.
-
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...