News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

When exec CodeSnippets.exe, it's auto change Window type

Started by Loaden, May 25, 2009, 02:43:16 PM

Previous topic - Next topic

Loaden

When exec CodeSnippets.exe, it's auto change Window type: From Docked to External.
I reset Window type to Docked, and it's ok!
But when i exec CodeSnippets.exe, it's auto change too.
XPSP3.

Pecan

Quote from: Loaden on May 25, 2009, 02:43:16 PM
When exec CodeSnippets.exe, it's auto change Window type: From Docked to External.
I reset Window type to Docked, and it's ok!
But when i exec CodeSnippets.exe, it's auto change too.
XPSP3.


Please give us the "exact" steps to re-create your problem.

Loaden

Quote from: Pecan on May 25, 2009, 05:08:59 PM
Please give us the "exact" steps to re-create your problem.
1. Run codeblocks.exe (is portable: default.conf with the same folder)
2. View - Code snappets, now, Opened the Code Snappets main UI.
3. CodeSnappets: Settings - Options -> Set Window Type to Docked and OK.
4. Quit Codeblocks.exe
5. run codesnippets.exe
6. quit codesnippets.exe (default.conf.cbTemp still exists!)
7. run codeblocks.exe
8. View - Code snappets
Now, CodeSnippets change Window Type to External

Pecan


Pecan

Quote from: Loaden on May 26, 2009, 12:19:15 AM
Quote from: Pecan on May 25, 2009, 05:08:59 PM
Please give us the "exact" steps to re-create your problem.
1. Run codeblocks.exe (is portable: default.conf with the same folder)
2. View - Code snappets, now, Opened the Code Snappets main UI.
3. CodeSnappets: Settings - Options -> Set Window Type to Docked and OK.
4. Quit Codeblocks.exe
5. run codesnippets.exe
6. quit codesnippets.exe (default.conf.cbTemp still exists!)
7. run codeblocks.exe
8. View - Code snappets
Now, CodeSnippets change Window Type to External


Since you've moved both CodeBlocks.exe, CodeSnippets.exe, and CodeSnippets.ini into a single folder, both exe's will use the single copy of CodeSnippets.ini .

Usually, CodeSnippets.exe uses a *copy* of CodeSnippets.ini. You've forced them to use the same file.

Right now, I can think of no solution to this.

So, when running in portable mode, either use the CodeBlocks plugin version of CodeSnippets *or* use the standalone external version. But not both.

Loaden

Quote from: Pecan on May 26, 2009, 08:56:28 PM
So, when running in portable mode, either use the CodeBlocks plugin version of CodeSnippets *or* use the standalone external version. But not both.
Oh. Have any way to made both use?
example: When run codesnippets.exe, it's not modify codesnippets.ini anything, but only read the codesnippets.xml ?

Pecan

Quote from: Loaden on May 27, 2009, 04:01:31 AM
Quote from: Pecan on May 26, 2009, 08:56:28 PM
So, when running in portable mode, either use the CodeBlocks plugin version of CodeSnippets *or* use the standalone external version. But not both.
Oh. Have any way to made both use?
example: When run codesnippets.exe, it's not modify codesnippets.ini anything, but only read the codesnippets.xml ?


No, it doesn't fit the design or intent of the program. However, you have access to the source and can change it as you like.

ollydbg

Hi, I find a strange problem.
I use the portable CB see:
http://forums.next.codeblocks.org/index.php/topic,10360.0.html

My codeblocks.exe was located in "F:\cb_svn\src\output"

But the "codesnippets.ini" was located in "F:\"

Is there something wrong?
Or this pulgin can't use the APPDATA related information to store its configuration?

Thanks
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Pecan

Quote from: ollydbg on June 21, 2009, 07:26:14 AM
Hi, I find a strange problem.
I use the portable CB see:
http://forums.next.codeblocks.org/index.php/topic,10360.0.html

My codeblocks.exe was located in "F:\cb_svn\src\output"

But the "codesnippets.ini" was located in "F:\"

Is there something wrong?
Or this pulgin can't use the APPDATA related information to store its configuration?

Thanks


CodeSnippets first looks for its .ini file in the executable folder.

If it doesn't find the .ini file in the executable folder, it uses the location reported by the Configuration Manager.

It knows nothing about APPDATA.

ollydbg

Hi, here is the steps to reproduce this problem.

1, unzip a nightly build or build the CB from SVN source. ( a clean CB, with out APPDATA folder)

2, copy CbLauncher.exe to the folder where codeblocks.exe locates. (suppose in "F:\cb_svn\src\output")

3, run CbLauncher.exe

4, then a "codesnippets.ini" will appeared in "F:\"

Any comments? :D, I will report to Biplab.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Pecan

On its first run, CodeBlocks is returning an empty string as the config folder location in OnAttach() for plugins.

CodeSnippets will have to look for the APPDATA envar.

I'll work up a fix for CodeSnippets.



kennedyusa058

I am not so knowledgeable about this matter. So i have to learn it. Thanks for the post. :P

pret auto

ollydbg

Quote from: Pecan on June 22, 2009, 12:08:49 AM
On its first run, CodeBlocks is returning an empty string as the config folder location in OnAttach() for plugins.

CodeSnippets will have to look for the APPDATA envar.

I'll work up a fix for CodeSnippets.




Thanks, I have see the fix in trunk.

By the way, I read the code below

wxString ConfigManager::LocateDataFile(const wxString& filename, int search_dirs)
{
   wxPathList searchPaths;

   // user dirs have precedence
   if (search_dirs & sdPluginsUser)
       searchPaths.Add(GetPluginsFolder(false));
   if (search_dirs & sdScriptsUser)
       searchPaths.Add(GetScriptsFolder(false));
   if (search_dirs & sdDataUser)
       searchPaths.Add(GetDataFolder(false));

   // then we have global dirs
   if (search_dirs & sdPluginsGlobal)
       searchPaths.Add(GetPluginsFolder(true));
   if (search_dirs & sdScriptsGlobal)
       searchPaths.Add(GetScriptsFolder(true));
   if (search_dirs & sdDataGlobal)
       searchPaths.Add(GetDataFolder(true));

   // rest of the dirs
   if (search_dirs & sdCurrent)
       searchPaths.Add(::wxGetCwd());
   if (search_dirs & sdConfig)
       searchPaths.Add(GetConfigFolder());
   if (search_dirs & sdHome)
       searchPaths.Add(GetHomeFolder());
   if (search_dirs & sdBase)
       searchPaths.Add(GetExecutableFolder());
   if (search_dirs & sdTemp)
       searchPaths.Add(GetTempFolder());

   // PATH env. var
   if (search_dirs & sdPath)
       searchPaths.AddEnvList(_T("PATH"));

   return searchPaths.FindValidPath(filename);
}


when CB fails to find the *.conf file at first running, it will return an empty string  :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.