Leaderboard

Gain with any messaging system is decoupling, so it makes sense to use it even if you make synchronous calls. But in multithreading scenarios, you need full fledged thread safe system capable of posting messages to a queue. In other words, asynchronous messaging. Anything else is just a crutch that can be used only in most simple scenarios.

Since the main untranslatable word is already "translated" as Chuck Norris the rest is simple: Chuck Norris doesn't read books, instead Chuck Norris write books.

This is so important! We must leave no stone unturned in our battle to persuade Embarcadero to change this!

can't compile the unit is not an error that should be included, its a result due to that ONE typo error in the codes. The errors should be reported exactly as whats in your codes.

I would suggest that if you want everything synchronous then don't use messaging, there's no point and you are just adding overhead for very little gain. We use asynchronous messaging extensively in FinalBuilder, yes it takes a bit of thought but then that's what programming is about. We use our own messaging library which is thread safe. Under the hood we also use omnithread library for some of the more complex threading.

Compilers generally try very hard if they find a bug. Then they don't know when to stop. D10.4 has made significant progress in this direction. The number of reported errors is several orders of magnitude lower. Even so, it is recommended to believe only the first mistake and ignore the others. I wouldn't make it a science.

I have to repeat this comment. Among other things, these books give excellent advice on naming conventions.

Example?

your problem is in your empty Table procedure TfrmEntry.EmptyTable(tbl: TADOTable; tablename: string); var MyCmd: TADOCommand; begin tbl.Active := true; MyCmd.CommandText := 'Delete * from '+tablename; MyCmd.Execute; tbl.Active := false; end; You have a local variable named MyCmd, but you never initialize it. Nor do you hook it up to the connection. try this instead procedure TfrmEntry.EmptyTable(tbl: TADOTable); var MyCmd: TADOCommand; begin MyCmd := TADOCommand.Create(nil); try MyCmd.Connection := tbl.Connection; MyCmd.CommandText := 'Delete * from ' + tbl.TableName; MyCmd.Execute; finally MyCmd.Free; end; end; Note you have 2 MyCmd variables. One is local to your EmptyTable procedure and one public to your form, but neither is shown to ever be created. You need to both instantiate a TADOCommand object (the .Create ) and you need to tell it what connection to use (setting the connection property). Don't forget to clean up the variable when done.

Isn't this just something that read metadata from WinMD and write wrappers? You can do that already so I guess the news is that they're generating WinMD from the SDK headers.

Could you give it a rest with the formatting? Your posts are hard enough to tolerate without it.

You need to be on a subscription, and using 10.4.1.