Anders Melander

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.

Why? It's a programmer error. Not a bug.

Variations of this question has been asked countless times. Always with the same answer: Don't do it. Why would you expect a different advice this time? Move the conversion into a separate process and kill that process instead.

I'm back. The point of my example was that, provided you use classes, you can generalize the tree structure and the function that traverses the tree. And you can delegate the operation to perform on each node to the caller via the predicate function. In your example you'd examine the Disabled value of the node and store the node in a list on match. The return value of the predicate specifies if the search should continue or stop. E.g. if you wanted to just test if the tree contains any node that match a certain criteria, the you'd return False on the first match. If Find returns False then you know there was a match. For each level in the tree you would specialize the generalization for that level to add the necessary data members.

If you could drop the records and use classes instead you could do something like this (very incomplete - I'm in a rush): type TItem = class private type TPredicate = function(AItem: TItem): boolean; private FItems: TList<TItem>; FDisabled: boolean; public function Find(Predicate: TPredicate): boolean; virtual; property Disabled: boolean read FDisabled write FDisabled; end; function TItem.Find(Predicate: TPredicate): boolean; var Child: TItem; begin if (not Predicate(Self)) then Exit(False); for Child in FItems do if (not Child.Find(Predicate)) then Exit(False); Result := True; end; var Item: TItem; Result: TList<TItem>; begin if (Item.Find( function(AItem: TItem): boolean begin if (AItem.Disabled) then Result.Add(AItem); Result := True; end)) then begin ...Result contains list of disabled items... end; end;

You're not nesting records. TList<T> doesn't contain a list of T. It contains a pointer to a list of T.

Why do we need google when we have @David Heffernan? David, the range and depth of your knowledge never cease to amaze me.

That's my experience too. Yup. I'm very satisfied too. There are some layouts that are hard to get right (layout in columns comes to mind), but generally it has saved me a ton of work.

Thanks for the explanation. It seems much more reasonable now. With regard to validation rules some purists will insist that they belong with the business logic on that tier, and I've seen many examples that implement n-tier that way (post data to the server - get an error message back), but in my experience that result in poor user experience. Much better to validate data as early as possible, on the client, and validate it on the server. If the server can supply the meta data required for the client to build the UI and do validation I see no problem with that. Just out of curiosity: Have you tried using the DevExpress layout control to handle different font sizes and resolutions? Since I started using it to layout dialogs I've pretty much stopped worrying about what resolution/font/sizes the users are using; The layout control takes care of it.

Yes. I'm sure we all experienced that a simple, innocent change ends up leading to much more work later one because we introduced a bug or side effects that we didn't think of.

Of course. If the customer can cover the development expenses directly, then that will increase the priority. If the change will benefit other customers, make the product easier to sell or benefit the product in some other way that can also increase the priority and lower the price of the change. There's still the matter of finite resources to take into account though. Even if the customer pays the expenses up front it still means something else is not getting done. I used to think I could solve the finite resources problem by implementing stuff in my spare time. Unfortunately that just created another problem as the QA, documentation and marketing departments was completely unable to keep up with the amount of features I could produce that way. I don't understand. So in the scenario you describe you're not the customer but the developer? If so, why do you have a request at all?