>> 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)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to