Anders Melander

If you're losing money using Delphi then you should find another tool. I'm assuming that was what you meant, but I have a hard time parsing what you wrote.

You might want to look at the Windows Event Tracing API. I haven't used it personally. What I have used is something like this: In your application the log entries are written to a thread safe, lock free, linked list (Windows SList). A separate thread reads from the SList and write entries to a circular buffer in a memory mapped file. A separate process reads entries from the circular buffer in the memory mapped file and write the entries to a disk files.

3) People assuming they know how and why Embarcadero prioritize as they do. It's easy to sit here and bitch about this and that, when you're not the one responsible for these things. IMO it's just noise.

It's left as an exercise for the student 🙂 The only code I have is a 10 year old example I once made in the Graphics32 newsgroup to demonstrate why cleartype AA shouldn't be used with the technique I described. Code and executable attached. Note that the code probably requires a 10 year old version of Graphics32 to compile. Here's the screenshots that accompanied the example (Looks like Win XP 😞 Shows regular text output with no blending. ClearType artifacts are clearly visible because of scaling. This is expected. Shows text output with alpha blending. Alpha is calculated from a single channel. Alpha blended Gray Scale AA is identical to opaque Gray Scale AA. Alpha blended ClearType AA shows asymmetry. Shows text output with alpha blending. Alpha is calculated from all three channels. Alpha blended Gray Scale AA is identical to opaque Gray Scale AA. Alpha blended ClearType AA is symmetric, but lacks detail. amAAtest.zip AAtest.zip

That will not preserve the alpha.

I would just use Graphics32 but you can do it with regular TBitmap's - it's just more work. What you do is draw white text onto a black bitmap. Make sure ClearType anti aliasing is disabled or you will get artifacts. Use regular greyscale anti aliasing instead. This bitmap can now be merged (RGB only, there's no alpha) directly onto the destination bitmap or it can be used as an alpha mask to draw in any color or pattern. To use it as an alpha mask you just transfer any of the R, G or B values (they're the same) to the A channel and then reset the RGB to whatever color you want.

Isn't that enough?

You already have a begin...end pair: with whatever do begin end; So why not just move the inline inside the begin...end and get rid of the with: begin var thisorthat := whatever; ... end; I see no reason to change the language so we can keep using with. Just get rid of it and forget it ever existed.

RegSaveKey still doesn't save in .reg format. Didn't you read my previous comment?

Killing all exceptions with empty try...except and disabling range and overflow checking amounts to the same thing. Not showing exceptions is a different topic. I don't believe the users should see the raw exception messages if it can be avoided, but when something goes wrong, that the application cannot reliably recover from by itself, then they need to know there is a problem and what to do about it.

Probability: There's an infinite number of locations far away vs. a relative smaller number close by. Therefore any object is almost guaranteed to be far away. How's my logic .-)

I'm currently working on a project where they (my client) have done everything they can to kill or hide exceptions. It's a nightmare. All I have to work on is vague reports from the users that "something" doesn't work, sometimes - and of course Range and Overflow Checks are disabled too, because they cause exceptions... I've tried removing all the empty try...except blocks but then the application can't even start because there are so many bugs in it. Luckily I only have 4 months left on that contract The sad thing is that I've seen this thing so many times. Some idiot developer can't figure out how to fix a bug to they hide it with a try...except and then it becomes a habit.

Like this: Flexible and Economical UTF-8 Decoder or this: A Branchless UTF-8 Decoder

Indeed; Hierarchical lock schemes are notoriously difficult to get right and most people don't even realize that if you have nested locking then you need to have a hierarchy. ... is pretty much a guarantee that one will happen sooner or later.

Yes, that's the one. The Microsoft RC compiler also has some (undocumented) features that enables two-way tooling (e.g. a Resource Editor); It can report on included header files, defined symbols and their values and a few other things.

Yes. I can see the documentation has definitely improved since I wrote the Resource Editor. File encoding doesn't appear to be mentioned though. Still the RC compiler supports a lot of undocumented stuff that is only mentioned in the source (which I might or might not have read).

It's better maintained and supports more features. The RC format is a proprietary Microsoft format with no formal definition so Microsoft will always be able to support it better. There are some RC features that are not supported by brcc32 but I can't remember which right now. brcc32 also has some features that are not supported by the Microsoft compiler, but it would be stupid to use those today. They're from the time when Borland still was contender (i.e. Borland C++ 5 era). Yes, but if you had included the file then we wouldn't have had to guess.

Your file encoding is wrong. Make sure that it's ANSI or UTF8 without BOM - or even better use the Win SDK RC compiler (set this in the project options). I've attached one that works. test.rc

Although the RC compiler will accept that, the correct format would be: STRINGTABLE BEGIN 0 "Hello" 1 "World" END I.e. no comma between ID and Value.

strict Applies to private and protected scopes. Works around the fact that private and protected members are visible within the same unit. I.e. it makes the visibility behave like one would expect. strict private indicates that the members are only visible to the class itself. They are not visible outside the class with no exceptions. strict protected indicates that the members are visible to derived classes too. reintroduce Used when a class declares a method with the same name as a virtual method in a base class. The only thing it does it to suppress the warning you would otherwise get. Basically you are stating that you are "hiding" a base class virtual method on purpose and not by accident. class sealed Prevents inheritance from the class. You will probably only use this if you're creating a class library/framework. There's no harm not using this if you don't really understand it's purpose. FWIW I would think all this is explained in the help.

I have designed and written several systems like that. Some have been for use by the end-user (for those that don't understand SQL or data relationship) and some have been for the internal use of an application (to avoid hard coding queries). My experience is that it never worked like it was supposed to. It might be that my designs was flawed but it's not like I haven't tried everything I could think of. It is a much more complex problem than what your description suggests. I actually know of a company that was run into the ground trying to solve it (well, there were other factors but this was the one that broke their back). The last system I implemented consisted of four major components: A data dictionary. Contains the meta data: Tables, columns, relationships, etc. A graph. Basically a Weighted Undirected Graph using Adjacency List that represents all tables and their relationships. A resolver. Given a start and ending node, finds the cheapest path through the graph using Dijkstra's algorithm. A query builder. Uses the input criteria (where), the output list (select) and the path through the graph (joins) to generates SQL. This works great for simple queries, small datasets or simple databases but once you throw a real world, large and complex database at it falls apart for several reasons. Here's just a few of them: It is not enough to find the shortest/cheapest path through the graph. Given multiple possible paths, the solution should optimally pass through as many of the "where"-tables as possible. It's not obvious what nodes to chose for the start and end node and the choice will affect the result. The criteria often needs to be qualified/scoped or the result will not be what the user expected. For example if the user asks the car database for "car.name" where "country.name=China" expecting a list of Chinese cars they will not understand that they receive a list of European cars assembled in China because the resolver took an unexpected path through the graph. There are many other cases where a choice, that affect the result, has to be made but the user hasn't supplied the information required to do so. In many situation the desired type of join to use cannot be inferred form the cardinality of a relation. The users often don't understand cardinality and most often don't even know where they will need to resolve a ambiguity with additional criteria. The query builder don't know how it should resolve a many-to-many relation or if it should resolve it at all. My recommendation is that you use a traditional query builder instead and concentrate your efforts on the documentation you mentioned.

I've already suggested that: The Windows common controls would not be able to support that format so you'd lose the standard support for copy/paste in all edit controls. There are ways to deal with this but they are not that simple.

I don't think anyone has a clue what you are talking about.

It's hard to tell from the "crystal clear" requirements but I don't think so. I'm guessing that since the OP is asking for clipboard functionality, and have rejected just copying data to and from a string, that he wants the copy/paste features of the standard Windows common controls used in the application to use his own internal clipboard. That isn't possible. It would be easy to use the clipboard with a custom data format, that is only understood by his application, but the Windows common controls are hardwired to use the standard CF_TEXT data format which is understood by everyone (thus the data can be considered "leaked").

Not really.