Runtime environment variables

[planodan]

Where are environment variables set for use when running a programs from within IDE?

I added them to Settings > Environment tab > Environment variables page > Created a group of env vars

I added group to Project > Properties > EnvVars option tab > Environment Variables page

When I run program within IDE, I do not get gui attributes, the settings for which come from config file set in environment variable.

When I run the program from outside IDE, invoking it from cmd line, it displays window attributes correctly.  Therefore, I assume the program is not reading the config file when run from inside the IDE.

[oBFusCATed]

You can always print the env vars in your application to verify that the correct variables are set or not.

[planodan]

Thanks for the reply, and yes you are correct.  I can also set them within the application, and I have tried that as well to no avail, all of which really should not be necessary, IMO.  I'm not being critical of CB, I just couldn't imagine that it did not provide for a way to specify runtime requirements, the starting point of which would be the runtime or object path. Therefore, the problem was not CB, but a matter of me not having learned where it was set or how it worked.  I assumed the "Objects output dir" in Projects > Properties > Build Targets was that setting, and if so, my assumption was either wrong, or because of a bug, it wasn't working.

My application is built to automatically look in the current directory ("Objects output dir"?) for the config file, then, if present, a path specified in a certain environment variable, read in and loaded on startup.  The environment variables control various system and other behaviors, some of which are customizable by the user.  That scheme works perfectly, and has for a long time, that is why the app or programs work correctly when run from a cmd prompt in the "Objects output dir".  The only exception is when I run programs from within CB.  I have been using CB for several years, and that particular feature has never worked, which means I can do a quick test of a program within CB, but I have to go outside of CB to see the program and app run as it should, i.e. with full attributes.  I decided to see if I could find and fix that problem, thus the reason for my question.

When a program is run from within CB, it behaves very similar to a program that runs on Unix/Linux in a forked shell where the environment variables have not been exported and therefore are not passed to the forked shell in which the program is running.  Since Windows does not function in that manner, I have to assume there is something in the way CB invokes a program that causes it to ignore the environment variables.

Sorry for the trouble, and apparently this isn't a problem for anyone else, so I will just live with CB the way it is, no big deal.

[BlueHazzard]

I can not follow. Can you explain your problem a bit more?
You have environment variables like PATH to set some configuration options?
Then you load things from a config file? And from within codeblocks it never works?
But if you copy things into the object output folder it seems to work?

Lets make things clear: The object folder is nothing where you should work in. This is only a place for object files that the compiler creates and not for user things...
If you application can not find the config file if you run it in codeblocks it is probably because the cwd (current working directory) of your application is wrong. If you run a program within codeblocks the cwd is set by codeblocks to the folder where the project file is. So if you use relative paths within your application the base folder is the project folder. You can set the cwd of your application when started trough codeblocks in project->Properties->Build targets->Execution working directory

About environment variables problems a minimal example project would be nice to test...

edit: Also what codeblocks version and what operating system are you using?

[sodev]

my assumption was either wrong

Thats the reason . The Objects output dir has nothing to do with runtime environment, this is the (base) directory where the .obj files that the compiler creates will be put, nothing else. However exactly above that setting, the Execution working dir, is what you need. This directory will be set as (starting) working directory of your application.

It's not a great design decision to depend on the current working directory to find files your application depends on, this forces the user to be in that directory at application startup, so this would fail if e.g. your application is in the system path and gets started from a random directory.

The Environment variables setting of CodeBlocks is working as intended for me.

Looks like BlueHazzard was faster, oh well, but you don't delete stuff on the internet

[BlueHazzard]

It's not a great design decision to depend on the current working directory to find files your application depends on, this forces the user to be in that directory at application startup, so this would fail if e.g. your application is in the system path and gets started from a random directory.

I would like to add that it is also bad design if you do not report errors about file loading or file not found to the user.

[planodan]

Thanks for the replies, and good points.  sodev hit on the problem in that it is the setting for "Execution working dir".  I have been leaving it as the default setting of "." for relative current dir.  Again, I made a bad assumption as to "relative to what?" which I thought was relative to the Objects output dir - which in my case ends in "...\objc\Debug" - i.e. I thought it was relative to where the program is located.  When I set it to include the same path - ..\..\objc\Debug - then everything works fine.  Totally my misunderstanding of how the path settings work.

As to the bad design comments, I totally agree with them, if the interpretation of my description were the way things were designed or being performed.  However, you don't have the full details of the design as I was trying to be as brief as possible to make the point that I was doing something extra by manually setting the envrn vars in a single program in an effort to troubleshoot the problem, not explain the complete design of the application's pathing details.  Obviously, I didn't make my point very well.  I further confused things with some bad wording in my effort to be brief.  When I said "look in the current directory" I did not mean the user's current directory.  It is the current directory for the application programs, or installed directory, as indicated in the Target setting for the application's icon on the Start Menu and/or desktop icon.  Sorry for the confusion.  As with any well designed app, the user can run the app from anywhere.  The app is not dependent on or relative to the user's location.

I think CB is a great product, and would have continued to think that even had my perceived problem been a real problem, and I'm glad to see that it does work the way I would have thought it should, and that it was my lack of knowledge or misunderstanding, not a lack of product features.  Now I'm smarter, so today is a success.  Thanks again!