Buggy behaviour with PropertiesFile


#1

I am loading and saving bools, and either saving, loading or both, fails completely. Some value is written/read, but whether its true or false seems to be quite random.

I have tried the exact same code on a Mac, and there everything works as expected.

http://www.notam02.no/~kjetism/Prefs.cpp
http://www.notam02.no/~kjetism/Prefs.h
[/url]


#2

I suspect that you’re probably leaking the properties file object, so it won’t always get flushed to disk? Do you make sure you delete the singleton when your program shuts down?


#3

Do you mean that in ~Prefs(), I should call “delete propertiesfile?”.

Is that really necessary? I set timeout to 0, so I though the file was written everytime setValue() is called? Besides, it didn’t make any difference if I was calling save() after each setValue() either.

I also tried to run the program on my own private linux machine today, and it works! Yesterday, at work, it didn’t. Could it have anything to say that at work the home directories are on a networked disk?


#4

You’d use clearSingletonInstance to delete it. Obviously you don’t want to leak, regardless of whether that’s the cause of this problem.


#5

(sorry, I mean deleteInstance(), not clearSingletonInstance)


#6

I’m sorry, I don’t understand anything… Is deleteInstance() a c++ function? (couldn’t find it with google) And is deleteInstance() closing the file?

I couldn’t find anything about this in the documentation…


#7

kjetil, he means that if you juce_DeclareSingleton a class, and then u use

MyClass::getInstance ();
then u should also call

MyClass::deleteInstance ();
:slight_smile:


#8

just to stay in touch with the topic…

doesn’t createDefaultAppPropertiesFile manage to create the directory and file if it is not present ? actually it is the first time i start the application and it always returns 0 :confused:


#9

[quote=“kraken”]kjetil, he means that if you juce_DeclareSingleton a class, and then u use

MyClass::getInstance ();
then u should also call

MyClass::deleteInstance ();
:)[/quote]

:?

I’m sorry, I have to read about more advanced C++ topics, you are on a very different level than me. :slight_smile:

I also don’t see why its necesarry to do anyting after calling save(). Juce use standard C fopen/fclose/etc. for disk access, and all filed are closed automatically when a program exits.

I’m now so tired of this that I’m probably going to surpass the use of propertiesfile. But I would like to help finding the bug, if its in juce.


#10

I use properties files very heavily on all platforms and never had it lose a value. You’ve not got more than one app open at once, have you? If that happened, they could be overwriting the same file with out-of-step data.


#11

Okay, my fault, most likely. Yesterday, while trying to debug juce_Propertiesfile.c, I inserted “out->writeString(“testing!”);” into save(), and forgot about it. Removing it now, and it seems to work.

Sorry for all the noise. There was a problem yesterday, but perhaps it was related to something else. It works now, at least.


#12

…yes, deliberately writing junk directly into the file could just possibly mess it up (!)

Hopefully not too many casual readers will see the title of this thread and assume that there’s actually a bug in properties file… I’d appreciate it if people could use less accusatory headlines until juce is actually proven to be guilty!


#13

[quote=“jules”]…yes, deliberately writing junk directly into the file could just possibly mess it up (!)

Hopefully not too many casual readers will see the title of this thread and assume that there’s actually a bug in properties file… I’d appreciate it if people could use less accusatory headlines until juce is actually proven to be guilty![/quote]

Yeah, I’m sorry about that. I was too tired yesterday, and didn’t even think about checking the files in a hex editor. That was the first thing I today, and it soon became very obvious what was wrong.

I have to give it to you, juce has an astonishingly low frequency of bugs. I’m working with a couple of other libraries right now in java/scheme, and I’m using more time debugging those than doing actual programming. It may be a bad excuse, but I’m probably too suspicious to other peoples code right now.


#14