>> 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