>> I'd suggest to touch it only as absolutely necessary. >> >> As for "sectionizing", I think it's not very good, >> since you need to be able to parse native .hbp files >> anyway, so section can get deleted, or not present at >> all. For pure cosmetic reason you could add them, but >> IMO it's not very polite to add unnecessary information >> to config files. >> > > By 'Sections' I mean ( .hbp parlance ) "Switches" and "Sources" > I am more concerned about "Souces" which user will be "adding/deleting" > the visual way. For that matter I do not want user to open .hbp > in a text editor, rearrange the information and then turn to hbIDE. > > How this can be achieved?
Just create a text file based on in-memory source and option arrays. I can't see anything complications with that. >> For a start you can simply write an .hbp file based >> on in-memory information using your own formatting. >> >> F.e. options first, empty line, source files, empty >> line, hbide options. >> >> Later this can be extended to keep track of change >> in-memory and try to replicate original format, with >> original comments, when writing out the file. >> > > Here it becomes difficult. If .hbp is tuned to receive > first swiches then sources, no issues. But if it is a mix > switch(es) | source(es) | switch... > then probably this cannot be achieved in reasonable way. > Also .hbp parser provides switches first then sources. Order doesn't matter, it's completely freeform. The reader accepts any order, your writer can write in any order which you find nicely looking. I proposed: options (one per line), newline, sources (one per line), but you can do it in any other ways. > hbIDE provides two sections to keep information: > 1) Compile/Link flags and 2) Sources. Just dump them to text file in any order. >> To make a little simpler, I'll add a new switch to >> hbmk2, which it will always ignore, so it can used >> to specify hbide (or other 3rd party tool switches), >> I plan to call it -3rd=<string>, so you can add >> hbide specific options, without fiddling with >> comment trick, like this: >> -3rd=-hbide-specialoption >> -3rd=-hbide-projectfriendlyname=Hello >> > > This feature will be nice but this will only needed for > couple of places which can be acieved with # at the end or start. Yes, it's meant to avoid this hack. Either the '#end'/'#start' or the '#hbide:<option>' comment hack. With this switch it stays clean. You only need to go trough the option array and find matches for ones that begin with "-3rd=hbide". IOW, we can drop the third special array in current parser. > In a nutshell, hbIDE needs sources to be located/deleted/added. > Rest of the part of .hbp can remain intect. > > Please keep in mind that we are building a .hbp in visually Sorry, for me the word "visual" doesn't add to the problem. All we are dealing with is reading a text file into arrays from disk (I already provided code for that), edit these arrays according to "visual" (or whatever else) events (using hb_AAdd()/hb_ADel()), and converting these arrays back to text file, and save them to disk. This looks simple, and it's enough for a start. [ To make it even better, tricks could be added to try to keep original formatting and also comment lines when modifying/saving these arrays, but let's concentrate on that later. ] Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
