Hi Pritpal, >> I believe you all this, but it's very inelegant IMO >> to use two config files for above technical reasons. It's >> IMO our job to find proper solutions to such problems. >> > > Yep, very inelegant, but I had no other choice. > I could not process Qt's byte-array to be returned as a > buffer of string. There are only two options, either supply > the filename of process a byte-array. > > Probably someone can help in this direction.
If you can get the byte-array from QT, you can use encode it using HB_BASE64ENCODE() and place it in .ini as simple text. You can process it with HB_BASE64DECODE() before passing it back to QT. >> IMO it's not a problem at all that binary encoded as >> text is included in any .ini file. Simply users won't be >> able to touch it, as they are not able to touch the >> exact same content in hbide.set. >> > > Yes, this can be documented, and I have included it in > FAQs section. I think it should be eliminated. Documenting wrong solution is not a solution ;) >> The other sad thing which I can read out from your >> words is that hbide.ini is not a standard .ini file >> but it's manipulate using some unique methods, which >> don't allow for extra content to be preserved. >> >> I think this should be fixed. >> > > Why it is "sad". User is never allowed to include the > contents of his choice in hbide.ini ( for historic reasons > I kept the extension .ini, it could been something else ), > as the contents of hbide.ini are subject to be re-written > at the time hbIDE exits, making it unfit for user-defined > contents. Because .ini is a well-known (quasi-)standard, where such behavior is expected. You can never know when it comes handy (f.e. plugins, 3rd party developers, or simple user comments placed in .ini). I guess you're using a read-it-all, write-it-all approach, while it should be a read_file -> get_item(s) and read -> put_item(s) -> write approach to make it work as expected. We even have functions for that in core (HB_INI*()). Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
