Question
I plan to make the plugins pack, however, for the base install of Code::Blocks, should I remove all plugins, or install the plugins that are checked by default in the standard Code::Blocks installer?
Previous Issue Solved
I'm still working on trying to make Code::Blocks portable, and I'm running into a very unusual issue.
when I use the code to redirect APPDATA to the /Data/settings directory, it only works if I have a message box pop up to display the new contents of APPDATA. I've tried setting a Sleep time from 200 up to 2000 and it just doesn't work, but if i use the messagebox, it does.
When it works correctly, the folder /Application Data/codeblocks is created under Data/settings, and the settings are saved in that location. The files are created on launch of CodeBlocks, and then modified as things change.
When it doesn't work, no settings files are created until codeblocks is closed, and then it only creates a "default.conf" on the root of the drive.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Well you can't redirect the APPDATA environment variable without admin rights, not to mention there are a host of other ways apps refer to it. Your only other choice is to move the data it writes there between APPDATA & Data\Settings similarly to how you move settings to/from PROGRAMDIRECTORY when an app expects its data in the directory it runs from. Since APPDATA is not a controlled setting you'll also have to check to see if data from a non-portable install is there and rename it before moving in the portable data, similar to how registry entries are now done. I don't know an existing launcher that does it, but lots of them do both of these things which shouldn't be hard to adapt.
formerly rayven01
I figured moving would be the way to go. I could rename an existing directory if it exists, then move the portable settings in...and then reverse the process, just like the registry stuff is handled
The developer formerly known as ZGitRDun8705
Did you see if this variable works?
System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("APPDATA", "$SETTINGSDIRECTORY").r0'Try popping that in somewhere before the launch, and see if it works.
Doing this requires admin rights, as I mentioned in my first post. That's right, MS coded in an explicit hack to prevent you from changing this one environment variable.
formerly rayven01
So does anyone know how PokerTH works on a limited account then?
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Good question. It does appear to work in PokerTH using dropmyrights. It's possible my source was wrong. I googled it when doing GnuCash and came across several sites claiming that it required admin rights to change. More than likely the application they thought used it was using another method like CSIDL_APPDATA or '%USERPROFILE%/Application Data'. Try it and see Zach.. maybe you'll luck out and Code::Blocks uses the real variable.
formerly rayven01
your source was wrong because I doubt John would use this method without ensuring that it works even on guest accounts.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
We tend to use the easiest method to accomplish something, even if it's not the recommended way (in this case, CSIDL_APPDATA is the "right way").
Oh, %userprofile%\Application Data doesn't work under Vista, at least not with UAC enabled. Typing that into the Run dialog or explorer's address bar results in an access denied error. Use %appdata% instead.
I know it's off-topic, but does %allusersprofile%\Application Data work under Vista with UAC enabled?
I just tried it as a limited user and had no problem.
You would certainly need Admin privileges to change the registry setting or wherever the API call gets its data from, but so far I'm not seeing a problem setting %APPDATA%.
MC
Thanks for help guys, I'll be busy all weekend, but I'll post back on Sunday night with my results.
The developer formerly known as ZGitRDun8705
The page is really stretched out! And I'm running at 1280x800! (widescreen, grumble grumble... I miss 800x600...)
It's stretched out? my code should be contained in a box with scroll bars, and that's the only thing that would stretch the page.
The developer formerly known as ZGitRDun8705
Need I say more?
It is likely the browser is broken, not the page. If it is the page, the admins would want to know.
Can you say what browser (and version) is doing that?
Is the entire page loading -- can you see the copyright/credits at the bottom of the page?
MC
The whole page loaded, yes. Browser is Firefox Portable 3.0 Beta 4, and I can confirm the problem doesn't exist in IE7 or Firefox 2.0. So indeed, it looks like I discovered a bug in FF3. Too bad I can't report it as I don't know what the conditions are to reproduce it...
also have this bug, although it seems like it only affects pages with pre tags in them, can you confim this Bruce?
Indeed, only with pre tags. Other threads here (as well as the Internet in general) render just fine; no horizontal scrolling necessary.
Well, it does look like there is a problem with the style sheet. I tried the CSS validation at W3c and got two hard errors for the <pre> tag's class for CSS 2.1.
It also looks like my response got put at the wrong place in the hierarchy...
MC
Any updates?
Its coming...I'm still having issues getting the APPDATA stuff to work...be patient.
The developer formerly known as ZGitRDun8705
That's really great news. Thanks so much for your time.
This code::blocks forum link references some relevant information. Maybe all you need to do is figure out how to make default.conf work for you. That with your registry settings that you have already identified may fix this bad boy.
*Edit*
And this link. And this here linky.
---
Jeffrey Wiggs
Loving God and Learning Laughter
That may work. I'll give it a shot tonight. Thank you very much
The developer formerly known as ZGitRDun8705
I'm anxiously awaiting a release. I'm still stuck with Dev-C++, because it's the only IDE with a portable version available.
Not that Dev-C++ isn't a nice IDE, but it's buggy as anything.
If the suggestions from the code:blocks forum work, I should have a release ready by friday night. If they don't work, it could take a while longer.
The developer formerly known as ZGitRDun8705
I have been eager for this one as well, but have not had the time to put it through the paces. My home computer is on the blink, and I don't like to install too much on my work computer. I already have MinGW, msys, cmake, and gnuwin32 on my portable drive in the PortableApps\CommonFiles\ folder. But having an IDE would be beneficial for my poor weak mind.
I look forward to your work on this, and maybe I can help down the line. Cheers!
---
Jeffrey Wiggs
Loving God and Learning Laughter
I have a new question now....its an odd issue.
The developer formerly known as ZGitRDun8705
My suggestion would be to put an execwait right after you set it and run a cmd shell so you can check the environment variables manually. If it still doesn't work after that and the variable is set right then it's probably using some other method of getting to the Application Data folder (USERPROFILE, registry, etc).
The only thing I can think of why the MessageBox would have any effect is perhaps it causes windows to sync the APPDATA variable with whatever method the program is using to access it besides the variable? I'm reaching here, it's definitely a strange one...
formerly rayven01
EDIT:
ISSUE SOLVED
CodeBlocks reads the USERPROFILE variable, not APPDATA, so I made that change...still didn't work...then I created an Application Data director under /Data/settings and it works...now for adding in the stuff to update all of the config files to use relative paths, or at least be able to update the drive letter.
The developer formerly known as ZGitRDun8705
How's the progress? Any chance for a development test soon?
I'm not in any kind of a hurry, so take your time making it work well
Nothing here right now... I might put something here later, who knows? Or will I? I really have to think about this...
Well I ran into some issues because Code::Blocks looks at the %USERPROFILE% environment variable, but stores it's settings under %APPDATA%, a subfolder of USERPROFILE. However, the path to APPDATA is handled differently in Win2K + XP vs. Vista. I have to write in some code to check what Windows version is in use, and have it handle redirecting the settings in a specific way for pre-vista machines and for vista machines.
The developer formerly known as ZGitRDun8705
I knew someone eventually would run into this problem. Why don't you try this? This is the 'MS proper' method for retrieving special folder paths, and should work regardless of OS. It's why I wrote it -
SHGetFolderPath
it's probably using CLSID to get the path to appdata which uses %USERPROFILE% in the path. I've run into this problem with a couple of apps. I sucessfully did what you're trying to do with having it switch and work right under xp or vista and having it change back when switching pcs but then i realized it still wouldn't work right because PCs in other languages have different folder names also. i think i can get it working now that i just thought of something, but in my opinion you should just have it copy the files over to the APPDATA env variable and copy back for a preemptive release and when either you or i get the userprofile stuff worked out you can update it to Dev Test 2 or something
Q: How do I make Code::Blocks portable?
* run / configure C::B as usual
Note: Code::Blocks will create a default.conf file that usually is placed into: "C:\Documents and Settings\[your_user_name]\Application Data\codeblocks" (or %APPDATA%) on Windows or your usual home folder ("~/") under Linux.
* place this default.conf file into the directory where the codeblocks binary is
* remove the default.conf file from %APPDATA% / home folder respectively
* just run C::B from within the C::B path and/or via script / link...
Note: Don't forget to remove all bad hacks you might have done previously that modify %USERPROFILE% and/or %APPDATA% on Windows.
Note: If C::B does not find default.conf (it's config) within the %APPDATA% / home folder it looks within the C::B directory (the one where the C::B executable is) next. If there is no config file, too it will be created in the %APPDATA% / home folder. So just make sure you are doing the right thing and C::B is portable just fine.
BTW: This does probably not apply for any other config file(s) where not C::B is the maintainer but e.g. plugins. The main config file just works like that.
Hope that is of some use. I fancied having a go over a year ago on this but never had the opportunity to start on it. You could look at recompiling it yourself from source.
Dell XPS M1530 Laptop
Intel Core 2 Duo T9300 2.5GHz
4GB Ram
256MB GeForce 8600M GT
I've seen that. I know that works, but I also read that some plug-ins havent been updated lately and won't redirect their settings properly. I may end up just doing a release that uses the method you mentioned anyway.
When I asked in the Code::Blocks forums, their responses weren't too friendly...the best i got was a link to the same info you copied here, and a "it's up to the individual plug-in developers to make sure their plug-ins work correctly"
The developer formerly known as ZGitRDun8705
Its a shame they didn't show you decent courtesy, they should take a look at a community like this to see how co-operation builds a good community for improvement and progression with common goals.
Dell XPS M1530 Laptop
Intel Core 2 Duo T9300 2.5GHz
4GB Ram
256MB GeForce 8600M GT
I was so sick of my University computers that I bought myself a laptop to run Code::Blocks but still would love to see Code::Blocks become a portable reality. I got to a crappy poor University. Yes, an University, not community college or Junior College. The country that I live in is so crappy.
Hi! What happened with C::B portable proyect? Has it been abandoned? I would love to have C::B portable!!
Faith sees the invisible, believes the unbelievable, and receives the impossible.
I was still hung up on how to handle the fact that Code::Blocks uses the %APPDATA% environment variable. I've decided to use the other option and just put the default config file in the Codeblocks main directory. I'll try to post a working beta this weekend.
The developer formerly known as ZGitRDun8705
Too bad. Something that requires that program is not installed on host computers is not really portable. I wonder why do they check appdata before own directory?
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
They actually do check their own directory first, it's the plugins that may or may not be an issue. When I asked about it in the C::B forums, the answer I got was essentially "if you use the method described on our wiki, C::B will be fully portable, but it is up to the plugin developers to make sure they wrote their plugins in the correct way so it checks the CodeBlocks folder first" that comment even held true for the optional plugins that come in the full code:blocks package :-|
The developer formerly known as ZGitRDun8705
Maybe I missed a relevant post, but if it uses %APPDATA%, shouldn't redirecting %APPDATA% be sufficient?
it uses %APPDATA%, but it is determined from %USERPROFILE%. but also, if the config file is in the program directory, it loads the settings off that, effectively portable, but not PAF compliant. Zach, cant you just modify the SumatraPDF launcher to make it paf compliant?
But there’s no sense crying over every mistake,
You just keep on trying till you run out of cake.
Yeah I could. The issue is ensuring that all the optional plugins work correctly. If the user adds no plugins, simply moving the config file between Data\settings\ and App\CodeBlocks would work just fine, but there is no guarantee that all the plugins will check the CodeBlocks directory for the config file first.
When I asked about this in the CodeBlocks forums, they basically said "sorry, we don't know, it's up to the individual plug-in developers to make sure they follow how CB works. (Look in CB dir for config, and if not there, create settings in APPDATA)"
The developer formerly known as ZGitRDun8705
hmmm. so the only true way to portable-ise this with plugins would be to use some form of an API hook....
But there’s no sense crying over every mistake,
You just keep on trying till you run out of cake.
i dont know. it could be possible that just putting the default config file in the Code::Blocks directory will work. i'd have to test every single plugin to ensure that they all follow the proper behavior.
The developer formerly known as ZGitRDun8705
Why would you have to test every plug-in when you are portabilising the main application? If there is a plug-in you are putting with it, it makes sense; but this is like asking John to test every Firefox, Thunderbird, The Gimp, or OOo plug-in before saying the app is portable.
Some plug-ins break portability. According to the developers, the plug-ins are supposed to follow a proper behavior. Of course they don't know which ones don't, mainly because it doesn't concern them as much as it does us. If it is needed, a plug-in compatibility page could be set up and linked to from the installer or the help page.
If someone comes across a compatibility issue, it could be addressed with that specific plug-in developer and indicated on the page.
Just some thoughts. Back to sleep now.
---
Jeffrey Wiggs
Loving God and Learning Laughter
good thoughts. i agree. i was rather sleep deprived and not quite thinking things through this weekend. i'll give CB another go soon. no plugins pre-installed, but i'll make a plugins package available i think.
The developer formerly known as ZGitRDun8705
New question posed, see top of main post
The developer formerly known as ZGitRDun8705
I keep MinGW in my CommonFiles folder "\PortableApps\CommonFiles\MinGW", I also use Digital Mars compiler and a couple of others. (I am mainly testing the waters, no real coding experience but no access to the same resources everywhere either. Hence the portability.)
A portable MinGW installer would be nice, but probably should be separate.
I like the idea of a plug-ins pack. But again, if necessary, we can install our own, especially if it is straight forward.
---
Jeffrey Wiggs
Loving God and Learning Laughter
I think Mingw should be separate, and in commonfiles, similar to how the java portabilizer works. I use mingw for several different things, and all of them using one install in commonfiles keeps things more sane. Preferably code::blocks would be pre-configured to look in commonfiles\mingw for the mingw files.
If you do go this route it would be nifty if you provided a separate download for a mingw installer that installed to commonfiles like the java portabilizer!
I wouldn't hold up the code::blocks test for this, though, since "portabilizing" mingw is as simple as copying an unzipped mingw directory to commonfiles.
formerly rayven01
sounds good to me. i'll see what I can do
The developer formerly known as ZGitRDun8705
One last question, see main post. I hope to get a package out later today or early tomorrow.
The developer formerly known as ZGitRDun8705
If you want maybe put the other plugins in a multi installer
Insert original signature here with Greasemonkey Script.
Alright sounds good to me
The developer formerly known as ZGitRDun8705
I would really like to see a portable version of this out, and i have my own idea (or course) for how to solve the problem. you can use the ProcessStartInfo Method (http://msdn.microsoft.com/en-us/library/system.diagnostics.processstarti...) in order to set the environment variables for the specific application that you are launching.
Hope to see one soon!
-Crazy2be