KeithLatham

Aaaaarrrrrggggghhhhh! I just spent an hour searching high and low for the MMX user manual. I know it was there - I've seen it and used it before. I just could not find the %$#@&^% thing! So I logged on here to ask for help finding it, but before I did, I looked at the About box to make sure I was talking about the current release. And what did I find? The link to the user manual of course! As my father used to say: "If it was a snake it would have bit me". So I'm just repeating this sad tale to ask if it would be too much trouble to add the link to the user manual to the MMX Menu? Thanks in advance Keith

Oh, yeah. My reading comprehension is a bit down today I guess.

How about myappname := extractfilename(paramstr(0)) Delphi Basics: paramstr

Invisible Formatting

Huh, yeah like Rudy said, how about Result := (condition) So your example if Property = 'A' then Result := 'N'; becomes Result := { start anonymous method } function(old, test, new: string) : string begin Result := old; if old := test then result := new; end; { end anonymous method } NO. anonymous method bad (IMHO) Much better is: function tester(old, test, new: string) : string; begin Result := old; if old := test then result := new; end; and then call it like function domything : string; begin {do something to establish the initial value of result} Result := tester(result, 'A', 'N'); end; Fundamentally, you are trying to do something that just is not in the syntax of the language. The designer(s) of the Pascal language made syntax choices that give the language its 'flavor'. Other designers gave other languages different syntax because it appealed to them or they saw 'easy' ways to implement them or whatever. It is pointless to choose an implementation language and then bang against the design choices inherent in that language. If you are used to something working one way in one language that you don't see in Pascal, then you need to understand that you are now working in Pascal, not in that other language. Your goal is not to write a program that 'looks like a similar program in language X'; your goal is to solve a problem in the language you're are working with. EVERY language whether it is Pascal, Perl, Python, Lisp, Cobol, APL, Fortran, Simula, Visual Basic, or anything else has constructs to accomplish your goal. But they all look differently when they do it, and that is what makes them different from one another.

I am glad too. But to address the part about you not understanding the construct, I would suggest that it resembles 'reverse Polish notation', and that is notoriously easy to implement in a stack environment. I have an book on interpreters somewhere in the bowels of my archeology site that some would laughingly call a 'library' that discusses exactly that method for implementing a Fortran interpreter.

Um, I misread your tListView as tTreeView. I think the problem you are experiencing is exactly why I chose tTreeView for my project. Mea Culpa.

As Mr. Einstein said, everything is relative. The point of origin on any graphics system is a design choice made by the original developer. If you weren't there to provide input, then not only do you not get to describe their decision as 'horrible', but you have absolutely no understanding about what considerations they pondered in making that decision. There are formulas for translating any coordinate system to any coordinate system - look them up if you want to make your code impenetrable. Or maybe there is even a system setting deep down in the bowels of the operating system that can define the coordinate system, kinda like you can set right to left typography. Have fun. You, know, sometimes choices like this are just arbitrary, there is no reason to do it any one of several possible ways, so they just picked one. That is the important part - pick one and be consistent. Sheesh.

I use an FMX ttreeview with no problems. Collapse/expand on clicking is part of the base functionality, you don't have to do anything special. Programming it is probably a bit trickier, just like in VCL (but different I suppose). For manually doing it with mouse clicks, there are little hot spot triangles next to the node text. Click on the triangle to expand/collapse. Your sample doesn't show the hot spot triangles. I don't see, off hand, how to turn them off/on.

Yes, that can be a good strategy if you need to maintain multiple versions of an application. But then you need to keep the the appropriate version of the utilities in the same 'domain' as the correct version of your application. That way if (when) you need to recompile to implement a bug fix, you have all the right sources in one place.

Using IFILEOPERATION 'FO_DELETE' against the target folder. Good point. That takes care of that dumb idea. Thanks.

OK, my project involves copying a file structure containing music onto a USB messagestick. The structure is thousands of tracks, in hundreds of albums, in many artists, in a few categories. So the file structure is along the lines of I:\Music\<Category>\<Artist>\<Album>\<track>.mp3 Before I start writing the output, I check to see if the target drive already has a Music directory and offer to delete it if so. Usually the the target is a USB message stick and I can just format it. But that doesn't have to be so, it could be a hard drive and I do not want to format that, so in that case I (currently) just delete the target directory, which for the large structure I am talking about can take many minutes. My question is, would it be (1) SAFE and (2) WORTHWHILE to do the delete in parallel? Say one thread task for each category? Or maybe one thread task for each 10 artists (I suppose an artist could be in more than one category so this wouldn't be very safe)?

Ahh yes, the 'ol desktop.ini file. I shoulda rememberized it. Thank you very much for the wake up call. I don't think it should be too 'off putting', but I sorta get what you're driving at.

Yes. I have a structure like this: \Projects\ \Projects\Project One\ <- contains structure for stuff for project one ONLY \Projects\Project Two\ <- contains structure for stuff for project two ONLY \Projects\Project Utilities\ <- contains dpr, dproj, etc for my Utility Generator \Projects\Project Utilities\source\ <- contains pas (and DFM) files for Utility Generator. \Projects\Project Utilities\DUNITX\ <- contains DUnitX test runners, etc In general my application dpr files will NOT specifiy the path to the utilities. An application units merely USES the appropriate unit that has already been compiled. I DO NOT want to recompile the utility unit every time - that is part of what makes it a general purpose utility. Only when I need a quick fix to utility unit will I SOMETIMES include the utility source in my dpr while I work out just what I need to do. Then when I have it right, I leave my application project, load up my utility generator, build ALL utilities for each target, and run regression DUnitX tests as appropriate. The advantage is that you have ALL your units in ONE consistent place, ALL your projects know exactly where to look, and you don't have to guess which version of the utility was compiled last time you built your application. I came to this setup after MANY years of upgrading from Turbo Pascal right up to RAD 10.2 (I haven't gone to 10.3 yet - probably in Feb for me) and noticing that I had dcu's all over the darn place littering up the drive. It really does pay to study the release/target search structures to figure out a consistent way of handling this stuff. You could end up with DCU's compiled for 32 bit all mixed up with DCU's compiled for 64 bit and resultant head scratching over what the heck is going on. What I haven't done yet is organized all my utilities into a namespace, but really its almost there. Some time back, before namespaces, I started naming my units consistently something like 'myCompany_APIUtilities', 'myCompany_PrintUtilities', etc. So I just need to change the '_' to a '.' - I think (and in only about a million places).

I use your Example A method and I put ALL utility units into a project by themselves. This means I have a Project 'my_UtilityGenerator.dpr' that 'owns' all my utility units that are common use routines (not application specific), 'my_APIUtilities.pas', 'my_DateUtilities.pas', 'my_MathUtilities.pas', etc. When I build 'my_UtilityGenerator' ALL utilities get built. There is a DUNITX testrunner included in the project directory as well. Any application project that needs the given utility set just names it in the uses clause - you need to coordinate the U-G output and the Application search path, of course (for all release/targets). Notice that if your application project has a LOT of utility units, you could do the same sort of thing, but your U-G could be remain inside your application project file structure and you could just load it into the project manager as part of a group. Occaisionally, I need to add functionality to a utility set or debug it further for the purposes of a particular application under development. Often when this happens, I add the utility to the application DPR, work on it there, and when finished, just go back to the UtilityGenerator.dpr and rebuild it there (alternative load the U-G project into the Project Manager too). Just remember to rebuild the utilities for each release and target you are supporting.