Attila Kovacs

@Stefan Glienke I've seen too late, already updated, also not sure anymore, but what else could be

https://docs.microsoft.com/en-us/windows/desktop/api/winhttp/nf-winhttp-winhttpqueryheaders If the function fails and ERROR_INSUFFICIENT_BUFFER is returned, lpdwBufferLengthspecifies the number of bytes that the application must allocate to receive the string. Looks like the -1 is the problem.

@Lars Fosdal TMyType has no inherited properties so if the list is empty this is the max you can get. (According to your example) If you have for example an object of TMyType3 type in the list, this is something else, then there is GetProperties and GetDeclaredProperties, or if Item is TBaseClass then begin tc := Item.ClassType; while tc <> TBaseClass do begin // GetDeclaredProperties comes here tc := tc.ClassParent; end; end; in this case you get the declared properties up to the TBaseClass which is not necessarily TObject so you are filtering with this your "own" properties. I think you can implement the version which fits your needs and which is perhaps also a bit different as the example above.

var ctx: TRttiContext; rt: TRttiType; tf: TRttiField; tft: TRttiDynamicArrayType; tc: TClass; prop: TRttiProperty; code MyVar := TMyOuterType.Create; ctx := TRttiContext.Create; for tf in ctx.GetType(MyVar.ClassInfo).GetDeclaredFields do // took FItems as a class Field as it was easier to work with if tf.Name = 'FItems' then // change it to GetDeclaredProperties for Properties begin tft := tf.FieldType as TRttiDynamicArrayType; rt := tft.ElementType; for prop in rt.GetDeclaredProperties do writeln(prop.Name); Break; end;

I've linked you a page where is written how for example firedac solves (helps) the problem. Rowset Fetching allows you to specify the number of records that will be fetched from the server in one network round trip. The rowset size is controlled by the FetchOptions.RowsetSize property. Bla bla... But it's not just that. The DB control you are using for displaying the data (and your code ofc.), should not force the dataset to fetch everything at the beginning, by doing things, like displaying sums on the bottom, auto sizing column based on values, sorting on client side, whatever.. Also consider splitting up the lists to live data, near past and history.

I have to guess, is this a kind of -we show a big list in a grid- kind of architecture defect? BDE delivered the first X row immediately meanwhile the rest was dled in the background, so it wasn't a big deal on a local network. I'm sure that those who updated to zeos lib back in the time faced the very same problem as it fetched everything and it took too much time. With most recent libs it's better, but it's even better not to load too much. I've for example a form where I can say, load me just X month of data. And of course just the fields the grid needs. Then there are the other type of apps, where you get an empty form (db controls without data), a search field, and a db-navigator. Yeah, it's ugly, not as transparent, but for sure the less resource taking variant. However, 10-15 minutes are just too much. If it's a local network there is something else too. It's 10GB on 100mbit and ~100GB on 1000mbit network.

You forgot the "I'm doing something wrong" part. Last time I've seen a similar case was a incidental table blocking. If one specific form was opened (anywhere in the network), some tables were blocked even for reading. I also don't know what is the architectural defect, if only few customers are complaining. I hope it's reproducible and you can narrow it down.

I've learned in the very beginning, that if I can't find answers to my problem, neither similar questions, then most probably I'm doing something wrong and the problem is non-existent.

I don't have the impression that the debug dcu code has been compiled with optimization. I'm also not sure if it's should have been. For exception reporting I'm using eurekalog, the call stack is okay, maybe not as verbose as with debug dcu's. But in principle I never release with debug dcu's.

@pyscripter Uhh, sorry, it wasn't. Now it's as slow as Berlin. Like the enhancements in rio were missing from the debug dcu-s. It's about 20secs.

@pyscripter Hi, I can't see any difference between release/debug under Rio/x86. Both are done in 12.x seconds.

You can't. A 14 years old research has shown that deleting / editing posts are better not allowed.

Which DAC and DBMS? Here is some reading for FDAC http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Fetching_Rows_(FireDAC) Set up a new project and start playing with the options.

Btw. the web installer also created a ...\BDS\19.0 empty key in the registry on a fresh windows install.

it's subjective. I like the IDE without skinning better 🙂

disable themes and dump modernthemexxx.bpl

Looks good. I'm still on Berlin 😉

I'm not using GE at all, but I can manage the same with 5 minutes of work.

it's in the help Note: Dest should point to a location with room for MaxLen + 1 characters, including the null terminator. too bad that the compiler can't detect the out of range

Look at your video and see how the focus is changing on your application meanwhile you minimize/restore the "other" application. Your SOT (stay on top) window has the initial focus, then your mainform then your SOT again etc.. etc... The same happens at me (Berlin U2), however it will always stay behind the "other" app, but my SOT form comes behind its parent every other time when the "other" app is in the foreground. Now, adding this code to the test app makes it behave every time the same, the SOT form is sent to the back, to the very back, and on activating to the foreground: (I've no clue if hwnd 0 is the correct value to mark it as empty, but you can introduce a boolean for it) It's hard to say more because I can't reproduce it, but it reminds me to the ancient "modal window behind it's parent window" malfunction, which was resolved by @Gert Scholten by setting the popupparent for the modal window. Let me know if you found out something. Btw, is this some Inductively coupled plasma spectroscope? var Form1: TForm1; actvfrmhdl: HWND; implementation {$R *.dfm} uses Unit2; procedure TForm1.ac(Sender: TObject); begin if actvfrmhdl <> 0 then SetActiveWindow(actvfrmhdl); end; procedure TForm1.da(Sender: TObject); begin actvfrmhdl := Screen.ActiveForm.Handle; end; procedure TForm1.FormCreate(Sender: TObject); begin actvfrmhdl := 0; end; procedure TForm1.Button1Click(Sender: TObject); begin form2.show; application.OnDeactivate := da; application.OnActivate := ac; end;

@Kryvich Btw, big thx for the plugin. I didn't know how those shortcuts was calculated 🙂

@Kryvich Thx but I will rather add menus to my own expert. I can't decide yet if I need shortcuts for these menus but I'm sure that I would have rather added extra menuitems to the editor popup as binding them to those insane shortcuts. I'm wondering if anyone is aware of the existence of them.

I'll consider. However used to GE re-configured many of the default key combos and we didn't make a big friendship. (I'm not using it)

My god, those combos...... Nice catch! I'll check them and maybe rebind them. Thx!

I've tried to call one of them and all I got was an AV. So I thought either wrong window or not implemented.