Opening project with undefined global variables

[Seronis]

If I open a project that attempts to use a variable that is undefined, C::B convienently pops up the display asking to enter information on it. This is nice and convienent but in instances where the information doesnt yet exist i dont want to have to enter anything.  Id like to be able to click cancel and have it, well, CANCEL.  Not just pop the dialog back up.  One time per instance of loading the project is enough.  If it refuses to allow me to compile or even if it sends garbage options to gcc i'll accept that.  But dont ask me to enter the variable information again and let me get back to work without having to task kill C::B.  If you must, refuse to load the project if a user refuses to enter info, but locking up the interface is extremely annoying.

[oBFusCATed]

You can enter some garbage settings to make it go away.
But I also think this is quite annoying, so +1 from me  :lol:

[thomas]

Agreed, it is annoying, but unluckily, this issue that has been existing for a long time is not easy to fix.
The global user variable manager works by returning a value if you ask for a variable, and by prompting the user if a variable doesn't exist yet. So far so good.

Now, the problem is, during the loading of a project and while code completion is running, it may be called a dozen times. If you hit "cancel", it's still being called again. That's the reason why the dialog keeps popping up.

To avoid this happening, one would need to add failure reporting to the user variable manager, and some kind of caching into the project loader and into code completion. However, that would very likely break something, since if the information wasn't necessary, the respective components wouldn't be asking for it in the first place (at least, I hope so!).
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

[oBFusCATed]

After reading your explanation, I think there is an easy solution: remove the cancel button and don't allow the user to close the dialog without entering something (proper message should be supplied)

[Seronis]

My issue is I dont want to enter garbage data once because I want it to come back up NEXT time if need be.  It either needs to be able to 'go away' peacefully or canceling it should unload the offending project.

And a point of curiosity, since we can -change- variables at any time and we can change them to 'wrong' info,  why cant it just flag a variable as defaulted and any further requests return a garbage string, or an empty string?  A garbage string would be far more useful than locking the interface and as long as the 'defaulted' flag isnt saved to disk it will properly ask next time the project is opened, right?  And if the user changes their mind, and decides to manually enter something useful for that variable during the session we can just clear the defaulted flag.  Then again I've admited to merely being a hobbyist coder before, and you're more experienced, so I could be mistaken about how easy it should be.  =-)

BTW not doing its job for compilation involving a 'dirty' variable is acceptible.  Stopping a user from opening a project that they might merely want to READ using their preferred IDE is not acceptible.

[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]

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

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]

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

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.

[MortenMacFly]

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

The problem here is: You mostly don't know that a project you want to open to inspect will contain user vars. So you wouldn't use the "read-only" option in the first place. The annoyance remains...

Edit:
What I don't get:
look at this code from UserVarManager:

Code

        if (Manager::Get()->GetProjectManager()->IsLoading())
        {
            // a project/workspace is being loaded.
            // no need to bug the user now about global vars.
            // just preempt it; ProjectManager will call Arrogate() when it's done.
            Preempt(variable);
            return variable;
        }
        else
        {
            wxString msg;
            msg.Printf(_("In the currently active Set, Code::Blocks does not know\nthe global compiler variable \"%s\".\n\nPlease define it."), package.c_str());
            InfoWindow::Display(_("Global Compiler Variables"), msg , 8000, 1000);
            UsrGlblMgrEditDialog d;
            d.AddVar(package);
            PlaceWindow(&d);
            d.ShowModal();
        }

...so glorious Thomas thought about that issue, but it seems not to work (anymore?!).

[thomas]

...so glorious Thomas thought about that issue, but it seems not to work (anymore?!).

Hmmm actually I had forgotten about having implemented that already  Yes, this was indeed supposed to work that way, no idea why it does not now.

What about doing some kind of open "readonly"

That's actually a good idea too. One could add a readonly flag which in this context means "return the value if it's there, and return an empty string if it's not there, but don't do anything else".
One would have to make sure that getting an empty string is handled gracefully, though. Project loading shouldn't throw up 20 "path not found" errors as a consequence (and shouldn't crash!), but the user should still know that something isn't quite right.