User forums > General (but related to Code::Blocks)

"Portable" Code::blocks?

<< < (6/7) > >>

mandrav:

--- Quote ---I no longer care to write code tightly coupled to the CB sdk. When the day comes that it's more dependable and stable, I may change my mind.
--- End quote ---

We 're not going to change the sdk for no reason. If you "don't care writing code" with the sdk, there's nothing more we can do.
When "you change your mind", we can discuss this again...

Pecan:

--- Quote from: mandrav on February 07, 2007, 11:14:09 pm ---
--- Quote ---I no longer care to write code tightly coupled to the CB sdk. When the day comes that it's more dependable and stable, I may change my mind.
--- End quote ---

We 're not going to change the sdk for no reason. If you "don't care writing code" with the sdk, there's nothing more we can do.
When "you change your mind", we can discuss this again...

--- End quote ---

I said: "write code tightly coupled to the sdk".

It appears you've already made up your mind. I don't care to discussion it further.

I'll take care of it myself. Then offer the code to others to make all our lives a little easier and CodeBlocks a little more pliable for the contributing programmer and reliable for the portable user.

stahta01:
Pecan:

I think this will fix keybinder, I have not tested it.
Note, it will still not work if the executable is on a no write media like CD-ROM.
Tim S


--- Code: ---Index: src/plugins/contrib/keybinder/cbkeybinder.cpp
===================================================================
--- src/plugins/contrib/keybinder/cbkeybinder.cpp (revision 3586)
+++ src/plugins/contrib/keybinder/cbkeybinder.cpp (working copy)
@@ -220,7 +220,10 @@
     // Create filename like cbKeyBinder{pluginversion}.ini
 
     //memorize the key file name as {%HOME%}\cbKeyBinder+{ver}.ini
-    m_sKeyFilename = ConfigManager::GetConfigFolder();
+    if (ConfigManager::relo)
+        m_sKeyFilename = ::DetermineExecutablePath();
+    else
+        m_sKeyFilename = ConfigManager::GetConfigFolder();
 
     //*bug* GTK GetConfigFolder is returning double "//?, eg, "/home/pecan//.codeblocks"
     LOGIT(_T("GetConfigFolder() is returning [%s]"), m_sKeyFilename.GetData());

--- End code ---

Pecan:

--- Quote from: stahta01 on February 08, 2007, 01:19:22 am ---Pecan:

I think this will fix keybinder, I have not tested it.
Note, it will still not work if the executable is on a no write media like CD-ROM.
Tim S


--- Code: ---Index: src/plugins/contrib/keybinder/cbkeybinder.cpp
===================================================================
--- src/plugins/contrib/keybinder/cbkeybinder.cpp (revision 3586)
+++ src/plugins/contrib/keybinder/cbkeybinder.cpp (working copy)
@@ -220,7 +220,10 @@
     // Create filename like cbKeyBinder{pluginversion}.ini
 
     //memorize the key file name as {%HOME%}\cbKeyBinder+{ver}.ini
-    m_sKeyFilename = ConfigManager::GetConfigFolder();
+    if (ConfigManager::relo)
+        m_sKeyFilename = ::DetermineExecutablePath();
+    else
+        m_sKeyFilename = ConfigManager::GetConfigFolder();
 
     //*bug* GTK GetConfigFolder is returning double "//?, eg, "/home/pecan//.codeblocks"
     LOGIT(_T("GetConfigFolder() is returning [%s]"), m_sKeyFilename.GetData());

--- End code ---

--- End quote ---

Thanks Tim, I'll give it a try.

thomas:

--- Quote from: stahta01 on February 08, 2007, 01:19:22 am ---I think this will fix keybinder, I have not tested it.
Note, it will still not work if the executable is on a no write media like CD-ROM.

--- End quote ---
Don't think you can compile that, because you access a private member from a non-friend class. Even if the compiler lets you do that (maybe with -fno-access-control), then you still obviously shouldn't, it's evil...  ;)


@Artoj: I haven't tested that recently, last time I tried was around June 2006 when it worked nicely. But even if it does not work, I won't look into it at this time either, because nobody really uses it now, and the horrible wxWidgets-based implementation will be replaced with a much nicer and more powerful cURL-based one in the not-so-far future (which is obviously entirely different).

Navigation

[0] Message Index

[#] Next page

[*] Previous page