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 » Fri Mar 20, 2009 6:56 pm

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 » Fri Mar 20, 2009 7:26 pm

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 » Fri Mar 20, 2009 7:32 pm

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 » Fri Mar 20, 2009 7:37 pm

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 » Fri Mar 20, 2009 7:41 pm

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 » Fri Mar 20, 2009 7:43 pm

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 » Fri Mar 20, 2009 8:44 pm

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 » Fri Mar 20, 2009 8:53 pm

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 » Sat Mar 21, 2009 10:54 pm

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 » Mon Mar 23, 2009 1:11 pm

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 » Mon Mar 23, 2009 1:42 pm

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: 3998
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Post by DavidHart » Mon Mar 23, 2009 2:23 pm

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 » Mon Mar 23, 2009 2:41 pm

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 » Mon Mar 23, 2009 3:26 pm

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