>> Now, this won't work on most ppl's computer, especially >> not on non-Windows ones, since it contains hard-coded >> paths for all things. >> > > Yes, I know, it is from my laptop and remarked as > "adjust your environments accoringly". > >> I don't understand why 'workingfolder' >> should be included at all, >> > > This is the location from where "build" process starts.
I don't get it. hbmk2 doesn't require any sort of information like that. It only needs the position of .hbp file and calculates everything dynamically. Same can be done by HBIDE, if it needs to do it for some reason. (f.e. to launch the app, but for this, -run can be used also) >> and why include 'location' >> which is supposed to be the directory where this file is >> _saved_ (and the dir pulled from the filename when opening >> it). >> > > -i is used as is. Interface does not have any "include location field" I don't understand, sorry :( If you open a file, you can calculate it's location, since if a full path is passed, you just use it as is, extract dir part. If a relative dir is passed, you can merge it with hb_dirbase(), and pull the dir then. I committed the function which can do the merging. >> DestinationFolder should be also a relative path to >> 'location', in this case simple left empty. >> > > Destination is location folder if kept empty. The value inside > is passed with "-o" in .hbp. I understand that, it's redundant though. >> Output is -o option. etc. >> > > Probably you do not understood visual design. > Though everything can be passed as flags, visual design > is better sited to fetch is from user and supply to the underlying > sub system. >> This was one reason I insisted on .hbp files, which >> doesn't suffer of this problem. >> > > This is all visual vs console. It shouldn't be. If you tell me this in advance I don't spend a few hours on the parser. > Again you are using the word "ignored". > Please think of hbIDE in visual terms. Everything > obtained is passed to sub-system, in this case, hbMK2. > Probably we are conflicting on re-use of components "as is". > Right ? Sorry but "visual" has no meaning for me in this context, especially when it's used as a tool to justify such design. Nothing tells that "visual" tools have to be based on wrong low-level concepts, storing unnecessary and platform dependent information in files. It also doesn't determine file formats used. (even Word managed to save its stuff in standard .xml files eventually) I'm very sorry Pritpal, but I have to realize we're on completely different grounds. I'm a little bit surprised because last time it again seemed we managed to sync the goals. But either I misunderstood you completely in all of these occasions, or these answer were just to silence me. It's quite disappointing to see these, and with such basic problems, I understand that HBIDE will most probably not become the tool of my choice in the future. (f.e. it's impossible to integrate it with so called "non-visual" environments. Using HBIDE is now an _all or nothing_ decision, but maybe this is what "visual" users are used to.) Anyway for now I turned HBQT/HBXBP/HBIDE off on my system, for me it apparently became a waste of energy. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
