Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Edit project as regular text file in editor plug-in

<< < (2/3) > >>

mandrav:

--- Quote from: rickg22 on November 08, 2005, 11:20:21 pm ---Oh, I see. Anywyay, what do you think of editing the checkforexternallymodifiedfiles function?

I find that a valid point, since sometimes i update from CVS but the project isn't reloaded.

--- End quote ---

The only bulletproof way of correctly reloading the project is to close and reopen it. Anything else and a million bugs are waiting to happen...

thomas:
Hmm, personally I am not enthousiastic about that, it's major overkill CPU-wise.

Reloading an editor may take 0.1 seconds, but loading a project can be 5 seconds, too, including parser.

rickg22:
I see. But what happens if the project is modified externally, and THEN I add a file? The external changes would be lost. And personally I don't have anything against closing and reopening the project.

killerbot:
That's the way I also implemented it, closing and reopening. Suppose automated checking on changes of the project file would happen, reloading can be just closing and reopening.
If you edit in the editor of cb, it should work rather well. If you 'GUI' changed something to the project and in the mean time you also changed the xml file for example in another editor (gedit, notepad, ..) then you are in for trouble. Because one save can overrule the other save, but this problem is also present for regular source files.

The reason I made this plug-in is, when your project (for example a library) has many targets (for example debug/release builds with different compilers for maybe different platforms); then I might be way easier to make an adjustment (say needed for 'nearly' all targets) if you could do that in the text xml file, instead of wading through all those gui panels.
Gui's are nice and user friendly but sometimes one needs more 'core?/hacking?' power.

Example :the project generated by the plug-in generator plug-in contain incorrect paths for compiler and linker (see another post by me). Each time I generated the plug-in starters I could adjust everything through the gui's. But I could just copy the correct stuff from a correct cbp xml file and copy it in the new wrongly generated cbp. Ok, fair is fair, if that bug is fixed, this example is no longer, but other occasions might benefit from this approach.

Another occasion where at minimum the reload command can be of use, is when you use versioning control system, and you retrieve from the system an older or newer version and CB had the project still open. So then my plgu-in comes to the rescue (you could close CB before you update the stuff from the version control system), it is automated then, or semi-automated since the user still issues to reload command. But it might be nice if CB detects the change and offers you the reload, the user then should decide what to do, if he had already made an unsaved change to the project and now he wants yet another different version of that project.

Hey, these are my pros, no doubt there are good arguments for the cons.

killerbot:
one more addition.
I do agree on the cpu penalty, but as like in my example (version control retrieval) you need to reload anyway.
If you just add a compiler switch in the gui way of working I guess there's no reloading and no parsing needed. If you close and open, this does happen, so in this case you suffer the penalty. But this might be still quicker then GUI travelling through all the spots where you want to change stuff (considering it is not just a single trivial change).

Navigation

[0] Message Index

[#] Next page

[*] Previous page