>> Did you try HB_INI*() functions?
>>
>
> No, never, I have my own code. I will try.
>
>
>
>> BTW, we're not even obliged to use a relatively
>> complicated .ini format. A simple flat format
>> is much easier to handle. F.e. this one also
>> stays compatible with .ini standard:
>>
>> F.e.:
>> ---
>> [hbide]
>> global.MainWindowGeometry=-4,-4,1291,814,
>> global.ProjectTreeVisible=1
>> global.FunctionListVisible=0
>> global.RecentTabIndex=-1
>> global.CurrentProject=
>> global.GotoDialogGeometry=
>> global.FindDialogGeometry=
>> global.CurrentTheme=City Lights
>> global.CurrentCodec=
>> global.PathMk2=
>> global.PathEnv=
>> global.CurrentEnvironment=
>> global.CurrentFind=
>> global.CurrentFolderFind=
>> global.CurrentReplace=
>> global.CurrentView= Stats
>> CurrentHarbour=
>> PROJECTS=F:\work\harbour\harbour\contrib\hbide\config.hbp,...
>> FILES=
>> RECENTFILES=f:/work/harbour/harbour/contrib/hbide/idetags.prg;f:/work/harbour/harbour/contrib/hbide/ideeditor.prg;f:/work/harbour/harbour/contrib/hbide/idedocks.prg
>> RECENTPROJECTS=f:/work/harbour/harbour/contrib/hbide/hbide.hbp
>> ---
>>
>> You can easily add the QT settings to that format.
>>
>
> It looks promising, but what if line length of some values
> increases the supported lenth.
We only need to deal with 32-bit systems (minimum),
so line length shouldn't be a problem, just allocate
enough room for a line.
>> It's not the extension, it's the placement.
>>
>> Probably '${HOME}/.hbide' should be the dir
>> to store .ini-like stuff on *nix. On Windows,
>> this could be '%APPDATA%\.hbide' dir, on OS/2
>> I don't know.
>>
>
> Someone has to jump in, even I do not know.
This part I know, so you can just listen to it :)
>> As for "resources" stuff, I don't know, probably
>> best would be to incorporate all of them right
>> into the executable in some ways, otherwise hbide
>> will need an installer to place these to the
>> expected on platform location. Or some *nix
>> users will give better ideas.
>>
>
> For resources to be inside exe, we need to compile
> and/or link with Qt's own engine. There is no other
> way. This is one point I could never resolve.
I see, that's not very useful for us then.
If there is a way to load .png files from memory,
we could create simple converted from .png to .prg
level strings and they could be loaded directly from
those.
Similar could be done with .ui files. If they could
be converted (or just simply enveloped) to .prg
files, they could just be compiled into binary
and loaded 'from memory'.
>> I can see .ui files in SVN. If they are not used,
>> maybe they can be deleted to avoid confusion.
>>
>
> No, it cannot be deleted.
> .ui is the feed for Qt Designer, .uic is the feed for
> Harbour. It is basically a .cpp which I parse and
> convert to object. For changes we always need .ui.
:( Sounds bad. Then at least they should be moved
to somewhere else, to make it easy to tell apart
source and distribution files. Probably .ui files
should be best moved to /contrib/hbide directly.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
