>> speedtst.prg
>> ---
>>
>> The parser I wrote for hbide, will recognize the
>> source parameters, so there is not need to mark them
>> with '[SOURCES]'.
>>
>
> Ok, I understand now.
> But what if anything after -3rd= is ignored. I mean the lines containing
> the token at begining with -3rd are ignored.
There are no 'lines'. The parser will consider the
whole file one continuous list of options. You can
have multiple -3rd (or any) options in one line.
Options are separated by whitespace. If you want to
include whitespace in any option, you need to put
the whole option between double-quotes.
> OR you just introduce
> -hbide= token which is reserved for hbIDE only and those lines are just
> stripped when hbMK2 parses .hbp.
This token is already introduced and is called:
-3rd=-hbide
or, in more generic sense this is the 3rd party option format:
-3rd=<app-prefix><app-setting>=<value>
As <app-prefix> I suggest: '-hbide'
<app-setting> and the rest is up to you.
[ hbmk2 doesn't create _any_ restriction on what
comes after '-3rd=' token, but it's yet good to
follow some good rules to not collide with other
3rd party apps using this feature. ]
> Above format is OK, but I need some more freedom of spaces without quotes.
I don't know why do you need it, but this
is not possible with .hbp format, or any normal
"script" format whatsoever.
> hbIDE needs [SOURCES] demarcation to know where user additions and
> removals are written back. I do not want to use hbide parser you sent
> except first time when new project is initiated. Now onwards, there will
> be only ONE project file, .hbp.
I don't understand your logic. You have a perfect
parser, which converts the .hbp file to an array
of options and input files. All your app has to
do is add/remove/change items in these two arrays,
and write them off to disk on save.
> First-time when project is initiated, hbIDE will ask for .hbp to load.
> It will be parsed with your parser, will fetch the user slots if he changes,
> and will write it back with above information. Then afterwards parser
> will never be called.
This is wrong.
> This approach will do two things:
>
> 1. All tokens will be on a different lines one each
> 2. All sources will follow next
Yes, you can write it to disk this way.
> What we loose, the tokens in between sources. And this will be the
> only noticeable difference, though I do not see a problem here, but you
> are the better judge of this situation.
Sorry, but I feel that you want to bend this
whole topic to the point it doesn't make sense
anymore and it's at least 4 times more complicated
then it should be.
The solution is in fact very simple:
---
IF hbpLoad( "test.hbp", @aOptions, @aFiles )
// do all the visual stuff, add/delete options,
// add/delete files
hbpSave( "test.hbp", aOptions, aFiles )
ENDIF
FUNCTION hbpSave( cFN, aOptions, aFiles )
LOCAL cFile := ""
FOR EACH tmp IN aOptions
IF " " $ tmp
cFile += Chr( 34 ) + tmp + Chr( 34 ) + hb_osNewLine()
ELSE
cFile += tmp + hb_osNewLine()
ENDIF
NEXT
FOR EACH tmp IN aFiles
IF " " $ tmp
cFile += Chr( 34 ) + tmp + Chr( 34 ) + hb_osNewLine()
ELSE
cFile += tmp + hb_osNewLine()
ENDIF
NEXT
RETURN hb_memoWrit( cFN, cFile )
---
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
