Major wxFileConfig bug Topic is solved

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
rodrigod
I live to help wx-kind
I live to help wx-kind
Posts: 172
Joined: Thu Jun 26, 2008 8:50 pm

Major wxFileConfig bug

Post by rodrigod »

I have found a major bug on wxFileConfig. I use wxWidgets 2.8.9 on windows with VC++ 2005. Also wxGtk 2.8.9 with OpenSuse 11.1 compiling with gcc (downloaded the latest stable version on the end of february dont know which one exactly right now)

After hours loosing hair and trying to discover why the hell wouldn't get the most important value from my .ini file I discovered that it doesn't return any value that has a big path. I doesn't need to be very big either. The path "canal0/driver" it returned perfectly, however "canal0/dllname" that has one more character it just returns my default string. I tried many different paths to comprove my theory I it always result the same, short names ok, bigger one no no.

I think that this is a really big bug, please anyone try to this at home. I will make a code exclusively to reproduce this bug and post here.

If there is anyway to fix this please someone help.

Thanks

Bye

edit: It is a little more random than I thought, because the path "canal0/caption" it managed to retrive the data. I am doing more tests and will post here any conclusions
mc2r
wxWorld Domination!
wxWorld Domination!
Posts: 1195
Joined: Thu Feb 22, 2007 4:47 pm
Location: Denver, Co
Contact:

Re: Major wxFileConfig bug

Post by mc2r »

rodrigod wrote:edit: It is a little more random than I thought, because the path "canal0/caption" it managed to retrive the data. I am doing more tests and will post here any conclusions
It is generally a good idea to do this part before calling "bug" in a crowded forum ;)

No offence, but chances are more likely that you are doing something wrong in your code, or in the ini file then there being such glaring bug in wxFileConfig that hasn't been noticed until now.

Bug or not posting code and a sample ini that exhibit the problem will probably get yo quite a few eyes that looking at it.

For what it's worth I have been using wxFileConfig in several large projects(size of code and users) for 2+ years and haven't had any issues with much much larger keys. win32 & gtk.

-Max
jacmoe
Experienced Solver
Experienced Solver
Posts: 64
Joined: Sun Feb 22, 2009 3:34 pm
Location: Denmark
Contact:

Post by jacmoe »

Let me tag along this post and say that I can't get this config class to work on Linux.
I'd say you have a documentation problem here.

I just guess that it doesn't work, because on Linux - by default - when developing and not doing a make install - the libraries and executables gets created with limited userrights.

I don't think your post was helpful at all Max.
It's just another way of saying RTFM. :wink:
rodrigod
I live to help wx-kind
I live to help wx-kind
Posts: 172
Joined: Thu Jun 26, 2008 8:50 pm

Post by rodrigod »

Yeah I kind of know that but I was working on theying to discover the problem and was getting p**** off. So I posted saying bug, now that I am building a application just to test this I will post exactly what happened. Sorry for the bad choice of words.

I will try to test it on linux next to see how it will work.

Can I still change the name of the topic so it won't cause any more problems?


Thanks
mc2r
wxWorld Domination!
wxWorld Domination!
Posts: 1195
Joined: Thu Feb 22, 2007 4:47 pm
Location: Denver, Co
Contact:

Post by mc2r »

jacmoe wrote:I don't think your post was helpful at all Max.
It's just another way of saying RTFM. :wink:
Well, I happen to think that RTFM can be very helpful ;)

But, I did mention that if he posted the code he'd get likely some help. I know I'd look at it. I'm just no good at speculating what might be wrong or going on without much more to go on than long config keys return nothing which then became random config keys return nothing.

-Max
mc2r
wxWorld Domination!
wxWorld Domination!
Posts: 1195
Joined: Thu Feb 22, 2007 4:47 pm
Location: Denver, Co
Contact:

Post by mc2r »

rodrigod wrote:Can I still change the name of the topic so it won't cause any more problems?
I think one of the moderators would have to do that.

I don't think it really caused any problems. I just think it is more likely some usage error than a bug.

-Max
rodrigod
I live to help wx-kind
I live to help wx-kind
Posts: 172
Joined: Thu Jun 26, 2008 8:50 pm

Post by rodrigod »

As I said it was a spur of the moment name, it could still be a bug but I am having trouble reproducing it to post here.

I have tried many things, and cant find a pattern. First I thought that the problem was the "name" word on the path, because "dllnames" and "dllnam" it could find, the same thing happened with "RemoteName". Discarded this hipothesis because it found "ReallyBigName".

The worst part is that small the exe that I built I can't reproduce this error at all.

Any one could have any idea why it would not load some random keys? These keys it never loads, but can´t find any pattern.

thanks
mc2r
wxWorld Domination!
wxWorld Domination!
Posts: 1195
Joined: Thu Feb 22, 2007 4:47 pm
Location: Denver, Co
Contact:

Post by mc2r »

rodrigod wrote:Any one could have any idea why it would not load some random keys? These keys it never loads, but can´t find any pattern.
I've none with out seeing the offending code and the ini file it has problems with.

-Max
jacmoe
Experienced Solver
Experienced Solver
Posts: 64
Joined: Sun Feb 22, 2009 3:34 pm
Location: Denmark
Contact:

Post by jacmoe »

mc2r wrote:Well, I happen to think that RTFM can be very helpful ;)

But, I did mention that if he posted the code he'd get likely some help. I know I'd look at it. I'm just no good at speculating what might be wrong or going on without much more to go on than long config keys return nothing which then became random config keys return nothing.
I agree with you fully.
Shooting in the dark leads to nowhere. :wink:
rodrigod
I live to help wx-kind
I live to help wx-kind
Posts: 172
Joined: Thu Jun 26, 2008 8:50 pm

Post by rodrigod »

I took a while to post the code here because I was doing some more tests. Didn't reach any conclusion, so here it goes:

Code: Select all

wxString		strAux;
wxFileConfig ini("","","",strGBIniName);
ini.Read( wxString(chrSection)+wxString("/Caption"),&strAux,"");
if( strAux!=wxEmptyString )
        strGBConfig[uchCanal] += strAux + ", "	;
ini.Read( wxString(chrSection)+wxString("/Driver"),&strAux,"");
if( strAux!=wxEmptyString )
{
	strDriver = strAux.Mid(0,78);
	strGBConfig[uchCanal] += txtLoadString(IDS_MODULO_COMM) +"= " + strDriver; 
}
wxString key = wxString(chrSection) + "/DllName";
ini.Read(key,&strAux,wxEmptyString);
This is the ini:

[Project]
Version=2.0.36
Created=17/12/2008 16:34:38
LastUpdate=17/12/2008 16:34:38


[Canal0]
DllName=AVBACNETG
RemoteName=192.168.0.69
RemoteNameSlave=192.168.0.69
TryNumber=2
TimeOutWait=2000
TimeOutRead=2000
Caption=BACnet/IP_Ethernet
Driver=BACNET
Tipo=REDE
Port=47808
Protocol=17
TimeSleepActivate=50
TimeSleepReceive=50
LogReport=0
Mostra Status=1
Mostra Estatisticas=1
IntervaloEstatisticas=500
FixedSizeMessage=0
PrioridadeParaMestre=0
LocalPort=0
GrupoDasEstatisticas=GRST

If I change the name of the entry to "dllnames" or "dllnam" it returned the right value. The same happened with RemoteName. But I tried other entries that ended with name and it worked perfectly. And if I changed the name of the section to "Canal1" it also worked.

I am going crazy with this.

Thanks

PS: this is not the whole ini, i put only the part the was near the entry I needed
rodrigod
I live to help wx-kind
I live to help wx-kind
Posts: 172
Joined: Thu Jun 26, 2008 8:50 pm

Post by rodrigod »

Just a little more info, while debugging I stepped into wxwidgets code and saw that it found the entry, the property HasValue was true, but it returned an emptystring
DavidHart
Site Admin
Site Admin
Posts: 4252
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Post by DavidHart »

Hi,
ini.Read(key,&strAux,wxEmptyString);
You're using: bool Read(const wxString& key, wxString* str, const wxString& defaultVal)
I've had problems with this: it sometimes seems to want a real wxString&, not a substitute.
Try: wxString defaultvalue; ini.Read(key,&strAux, defaultvalue);

Regards,

David
rodrigod
I live to help wx-kind
I live to help wx-kind
Posts: 172
Joined: Thu Jun 26, 2008 8:50 pm

Post by rodrigod »

After digging realy deep into wxwidgets I saw that when creating the wxFileConfig variable it reads the whole ini and sve it. When doing this it reads conrrectly my dllname entry, however in some moment after doing this it loses the value.
Going to investigate some more to discover when and why it does this.

Thanks
rodrigod
I live to help wx-kind
I live to help wx-kind
Posts: 172
Joined: Thu Jun 26, 2008 8:50 pm

Post by rodrigod »

Found it!!!

The problem was that at some point dont know when, it was created a ini on my local documents and settings, and when I initialized the ini variable it read first the global file then a bogus ini file with the application name that corrupted some of the data.

But I found one "problem" with the this class. It is that it doesn't behave the same way as the windows GetPrivateProfile when reading the ini. So every time you need to write a windows path you need to use "//" instead of "/", which is kind of annoying.

I don't know what is the need of this, since when reading a file the caracters are all read correctly (the enter is read as '\n', tab as '\t' and so on). In my opinion there was no need to consider that the ini file is wirten as a C string show be writen. What do you think?

Thanks
Post Reply