User forums > Using Code::Blocks

Opening project with undefined global variables

<< < (2/3) > >>

Seronis:
Hope my tone doesnt come off as sounding unappreciative either.  I love C::B more than any other IDE i've used.  I have a full copy of M$VS.Net Professional that I got for free as a gift that collects dust.  So having a user prefer C::B over a product that normally costs insane cash (and didnt even have to pay for it) shows the quality of what you guys do.  Keep it up.

MortenMacFly:

--- Quote from: thomas on February 09, 2010, 11:03:28 am ---Or, one could add a flag into the global user variable manager which marks a certain variable as "undefined, don't ask again", but then it won't do its work for compilation any more :(

--- End quote ---
What about resetting this flag in EndWorkspaceLoaded all the time? It seems the most convenient way to me to do it that way. Because most likely the user won't / can't work with the workspace / project(s) loaded anyways. So the next logical step would be to close the workspace (and not compiling it / modifying it).

However, I must admit that it annoys me, too. I usually kill C::B in that case using the Task Manager or simply setup a dummy value.

thomas:
Well, the problem I see with this is that one would be trying to find a solution to make a component that works comply with components that don't work and that you don't have control over.

The reason why the dialog keeps popping up again and again is that both project loading and code completion are calling the manager a dozen times for the same value, instead of a single time. So, this is a symptom, not a cause.
One would have to save the state somewhere and unless one was to rewrite much or most of the manager, the only viable solution would be to put some magic value into the map.
Also, some meaningful value would have to be returned, since otherwise you would possibly get the same number of dialog boxes, only this time they would be of the "path not found" kind.
And lastly, you rely on some plugin which may or may not be working correctly, and which may or may not be under your control to reset a state that will otherwise be saved permanently when the application exits.

All in all, I am not sure if this would make things better or worse, to be honest.

MortenMacFly:

--- Quote from: thomas on February 10, 2010, 11:35:31 am ---All in all, I am not sure if this would make things better or worse, to be honest.

--- End quote ---
I take that as a vote against doing the proposed change in uservarmanager/macrosmanager and prefer to change projectmanager and CC instead.

So you'd propose instead of calling to replace macros directly from these components we should "tunnel" the call through a caching which takes care of:
a) avoid multiple calls (meaning caching instances of macro replacements, thus making duplicates of what uservarmanager/macrosmanager "knows") and
b) have some kind of "annoyances" dialog there allowing to abort / silence the loading / dialogs.

I just see one thing:
For the proposed use case of opening a project to just "look" at the code and use C::B as viewer / navigator only (which is perfectly valid btw.) there will never be a valid configuration possible as the dependencies may indeed not be resolvable. Thus after loading the workspace/project is indeed in an "undefined" state when it comes to macros. So yes: Any further processing might fail. We can do some "magic" in the components, too - but don't you think such functions should really be part of the uservarmanager/macrosmanager?

Jenna:
What about doing some kind of open "readonly", do not replace any macros and disable compiler and debugger. CC might partly work (at least for the project itself), as long as no macro-replacement is needed.

I don't know, whether it makes sense or can be done easily.

Navigation

[0] Message Index

[#] Next page

[*] Previous page