Leaderboard

Probably nobody will help you with this by Teamviewer or similar. You better copy the errors into the thread here, so that we can help you. ccr.exif works like a charm here with Rio and all predecessors for years.

We use our https://github.com/synopse/mORMot/blob/master/SynLog.pas Open Source logging framework on server side, with sometimes dozens of threads into the same log file. It has very high performance, so logging don't slow down the process, and you can make very useful forensic and analysis if needed. Having all threads logging in the same log file is at the same time a nightmare and a blessing. It may be a nightmare since all operations are interleaved and difficult to identify. It is a blessing with the right tool, able to filter for one or several threads, then find out what is really occuring: in this case, a single log file is better than several. For instance, one of our https://livemon.com server generates TB of logs - see https://leela1.livemon.net/metrics/counters - and we can still handle it. This instance for instance is running since more than 8 months without being restarted, and with hunderths of simultaneous connections, logging incoming data every second... 🙂 We defined our simple and very usable log viewer tool - see http://blog.synopse.info/post/2011/08/20/Enhanced-Log-viewer and https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_103 This is the key to be able to have something usable from heavily multithreaded logs. So if you can, rather use a single log file per process, with proper thread identification and filtering.

This open source project basically can replace dcef3 or cef4delphi (for embedding the Chromium browser into your program), but the size is much smaller - 6mb zipped. I guess not everyone in the English community knows about it since it's hosted in the Chinese version of github :D https://gitee.com/LangjiApp/Wke4Delphi Basically it's a Delphi wrapper for: https://github.com/weolar/miniblink49

Agree with NIRAV KAKU in the principle but anyway if you want to access LiveBinded fieldname of a column, fieldname is the wrong name you have to search a membername. My test in ideal conditions (only one StringGrid, only Stringgrid is Binded) Consider this code, list of all columns linked procedure TForm1.Button1Click(Sender: TObject); var B : TContainedBindComponent; C : TLinkGridToDataSourceColumns; ib,ic : integer; begin // have to search in the whole bindingslist for ib:=0 to BindingsList1.BindCompCount-1 do begin B:=BindingsList1.BindComps[ib]; // check if the component is the stringgrid if (B.ControlComponent=StringGrid1) then begin // look for all linked columns for ic := 0 to TLinkGridToDatasource(B).Columns.Count-1 do begin C :=TLinkGridToDataSourceColumns(TLinkGridToDatasource(B).Columns); Memo1.lines.add(c[ic].MemberName); end; end; end; end; From this you can write a function, something like function FieldNameOfGrid(const Grid : TCustomGrid; col : integer) : String function TForm100.FieldNameOfGridCol(const Grid: TcustomGrid; const col: Integer): String; var B : TContainedBindComponent; ib : integer; begin for ib:=0 to BindingsList1.BindCompCount-1 do begin B:=BindingsList1.BindComps[ib]; if (B.ControlComponent=Grid) then try result:=TLinkGridToDataSourceColumns(TLinkGridToDatasource(B).Columns)[col].MemberName; break; except result:=''; end; end; end; Perfectible I think but working, even with unlinked columns, but only if columns are defined

There was nothing in what I wrote that was directed at you personally but if I have offended you I apologize for that. I really do understand your POW and I agree with most of the problems you and others have, repeatedly, pointed to. What I object against is the one sided, two dimensional, demonization of Embarcadero. I too have been down the road of a disgruntled customer. I experienced a great misalignment between the needs of me and my company as a customer and the direction Embarcadero took with Delphi. There was also the whole Resource Editor debacle, which I won't go into here. We knew from experience that complaining about things didn't make any difference, so we decided to vote with our money. After Delphi XE we cancelled all maintenance contracts and recommended to our clients that they do the same. Personally I stopped participating in the community and I no longer released any open source stuff. Basically I took my ball and went home. That was 10 years ago. Around the time Delphi 10.2 was released I had finally cooled down. I had also come to the realization that the primary reason why I became a disgruntled customer in the first place was that my expectations were wrong. I had once seen Borland as "my friend" and I hadn't adjusted to the new reality of Delphi struggling to survive and stay relevant. I expected them to behave in a certain way and when they didn't I was disappointed. I not taking all the blame for that because they certainly tried to make us believe in the dream. I'm taking the blame for believing it.

I don't know for certain, but I seem to recall there was a language being floated around the time Anders was stolen from Borland that may have turned into C# a year or so later. MS thought C++ had too much irrelevant stuff in it and not enough things for supporting the evolving technologies they were looking at. They had a couple of people on the C++ standards committee who made several proposals that routinely got shot down. "partial" classes are ideal for supporting auto-generated code. They allow you to spread the contents of a given namespace across multiple files. Personally, I think the whole notion of a "file" as some kind of a meaningful unit of programming has far outlived its useful life. C# has incorporated this in its design, although the programming environment doesn't take much advantage of it. Delphi hasn't even started to move in that direction. The motivation behind this is simple: the IDE should allow us to compose fragments of programs that are saved to a database rather than files, and compose them into larger chunks. Not in contiguous globs of text that we currently call "units" but as little chunks of logic that get glued together as-needed for whatever problem we're solving.

I don't like it either. Like everyone else I would love for every bug to be fixed yesterday, the compiler to produce better code, the VCL and RTL to support all the new shiny stuff and that my wife was 20 again. I'm assuming Embarcadero has the same wishes (Okay, maybe they don't care about my wife) but obviously their first priority is to make money. They're not in it for the Karma. I myself used to be very vocal in the field test newsgroups in my critique of the decisions made by the various owners of Delphi during the years, to the point that I was asked not to participate in the field tests. So it's not like I don't understand the frustration or the need to vent it. However I also know that I don't know all about why they make the decisions they do. If I were in their shoes I might make the exact same decisions. Of course they make mistakes. They make huge mistakes sometimes *cough* Delphi 8 *cough*. That is obvious to all. But it gets really tiresome to constantly read this whining about how bad Delphi is or how evil Embarcadero are. It's leading nowhere. Not a day goes by that I don't curse some part of Delphi to hell, but at the same time Delphi has payed for my house, my cars, my children's education and all my vacations. Anyway, this has nothing to do with hash tables. Sorry for hijacking the thread.