Categories and file types defined lost on C::B restart

[MortenMacFly]

Dear all,
If I setup a new file type using "Project" - "Project tree" - "Edit file types categories" (by the way: the menu entry has a space too much) then this works perfectly for the current session. Hence if I restart C::B they are always lost. I've had questioned this in another thread already but I am unable to find this thread (but it was a different topic, anyway). What looks very strange to me it that within the C::B config-file the new file type is present and doesn't get lost. Any ideas?

Morten.

Edit: I guess I have tracked down the issue to filegroupsandmasks.cpp: It seems the file groups are tried to be read from a sub-group called "/file_groups" of "/project_manager" but written to directly to "/project_manager"... if I'm right...?!

[MortenMacFly]

I think I was right, I' ve tracked down the reson to filegropusandmasks.cpp. I've filed a bug report on sourceforge and attached a patch to fix this issue there (https://sourceforge.net/tracker/?func=add&group_id=126998&atid=707416). Applying this fix makes the feature work again. Hence there will be remaining artefacts in the config file that should be deleted manually: section "<project_manager>", every sub-section that starts with "<groupX>" whereas "X" is an integer-number.

Morten.

[thomas]

If I setup a new file type using "Project" - "Project tree" - "Edit file types categories"

Wow, you're telling me about an entire submenu which I had never seen

(by the way: the menu entry has a space too much)

No, it has not?

I'll look into it after dinner (~20 mins). Thanks for pointing out.

[MortenMacFly]

Wow, you're telling me about an entire submenu which I had never seen

I am using this regulary to add the "Fortran sources" file type as described also in the WiKi. It's very helpful!

I'll look into it after dinner (~20 mins). Thanks for pointing out.

I think this was an easy one that's why I was able to fix it... :lol:

Morten.
Edit: Mahlzeit!

[thomas]

Done. Thanks

[280Z28]

That patch doesn't work for the unicode version. Look at the diff between what you just did for this and how it was changed here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1385378&group_id=126998&atid=707418

Keep that style in mind because it consistently breaks the Unicode builds.

Another example of the exact same problem and how it was fixed:
http://sourceforge.net/tracker/index.php?func=detail&aid=1386025&group_id=126998&atid=707418

I'm not sure why it occurs, but I found a sure way to prevent it in the future.

[thomas]

Hmm... yes, Printf does have a problem, that is the cause of the Cv1 bug too. If only I knew what it is.
Using operator<< is no real alternative, it works in this case, but not in all. I'll apply your patch tonight (thanks for pointing that out), but we must really find out how to use Printf correctly, so we can do things like Printf("blah blah %d blah %s", someInt someString), and it still works in Unicode, too. Maybe it is as simple as writing %S or %sL instead of %s -- don't know. I was unable to find any kind of useful documentation on this.

[killerbot]

how come we cant make operator << work in all occasions, we could define overloads for the missing parts ??

personal note : die printf die 

[thomas]

Hmm... tell me... how did you make this patch?

I just looked at it and wondered that it was apparently already applied. But that is not the case!

Your patch file says it is against revision 1563, but the file uses operator<< since revision 1340 (the path was modified in 1557).

Revision 1563 is well after 1557, so how can this be? Where do you take that Printf from?

Code

D:\desktop>svn diff -r1556:HEAD svn://svn.berlios.de/codeblocks/trunk/src/sdk/filegroupsandmasks.cpp
Index: filegroupsandmasks.cpp
===================================================================
--- filegroupsandmasks.cpp      (revision 1556)
+++ filegroupsandmasks.cpp      (revision 1578)
@@ -72,10 +72,10 @@
        {
         FileGroups* fg = m_Groups[i];
         wxString key;
-        key << _("group") << i << _T("/") << _T("name");
+        key << _("/file_groups/group") << i << _T("/") << _T("name");
                conf->Write(key, fg->groupName);
         key.Clear();
-        key << _("group") << i << _T("/") << _T("mask");
+        key << _("/file_groups/group") << i << _T("/") << _T("mask");
                conf->Write(key, GetStringFromArray(fg->fileMasks, _T(";")));
        }
 }

[thomas]

how come we cant make operator << work in all occasions, we could define overloads for the missing parts ??

Oh, we can... but it is tedious. append() works fine too (with strings only , of course).
It is just Printf that seems to cause problems. Everywhere it is used, something screws up.

[280Z28]

NOOOOOOOOOOOOOOOOOOOO Printf is what works!! << is what does NOT work (FOR INTEGERS)!!

 :shock: :lol:

[rickg22]

why not just use an int2s function and forget about which part doesn't work?

[280Z28]

why not just use an int2s function and forget about which part doesn't work?

Probably the reason I didn't use an int2s() function is I didn't think about it.

However, looking back on it, take a look at this line in filegroupsandmasks.cpp:75

Both of these ways should work in the Unicode version. One fixes the problem with int2s() and one with Printf(). I greatly prefer the Printf() in this case because it is immediately obvious exactly the type of string you are creating. The longer one with int2s() requires you to "build" it in your head so to speak.

Code

key << _("/file_groups/group") << int2s(i) << _T("/") << _T("name");

key.Printf(_T("/file_groups/group%d/name"), i);

[Michael]

Hello,

How about wxMBConv classes?

I am not sure, but I think they could be used, or?

Michael

[thomas]

How about wxMBConv classes?

Does not avail. Converts two-byte to variable length and vice versa. I tried, too, it only messes up the string completely.