A.M. Hoornweg

Hello World, Can anyone please point me to some instructions on how to manually install the Android SDK in such a way that it'll work with Delphi Rio (in a VM)? I just can't understand how Embarcadero didn't have a contingency plan for keeping GetIt online. A two-weeks outage is soooooo unacceptable. Regards, Arthur

... And it's down again. Sigh. The Quality of the Portal needs improving.

Yes, suddenly works now. No captcha in sight.

Like I said, I do test my apps on Windows 10 (using remote debugging, on a system with 3 monitors). But I do the compilation inside a Windows 7 VM, on a stable system that doesn't change all the time.

The web site responds "Sorry, an error occurred trying to log you in - please try again." (and I see no captcha).

YES I can, but it takes a whole minute to respond.

It doesn't feel right for me to develop under an operating system that's constantly changing. It happened 3 times to me in the past 12 months that a Windows update broke something serious on my Windows 10 system. I feel much safer developing inside a Windows 7 x64 VM. To test under Windows 10, I use remote debugging.

The IDE which you use to edit the project and the compiler which you use to build & deliver need not be the same... I use FinalBuilder for my builds so I can specify which compiler to use. So I can edit in one Delphi version and build using another. Often, if I migrate a project to a newer Delphi version, I want to avoid breaking things. So I keep editing using the old IDE until it compiles without warnings in both compiler versions. This way the conversion can be a gradual process and I can still publish new releases and bugfixes if the conversion isn't ready yet. And sometimes it is useful to deliberately use an older compiler in the build process if it produces much smaller compiled code. The difference between Delphi 2009 and Rio is quite dramatic. Now I know that this doesn't make much sense in single-executable projects but it does have an impact if the project contains two dozen DLL's that suddenly triple in size.

If I were you I'd hang on to that D2009 version for a while, at least if the size of your executables and DLL's matters. D2009 produces much more compact executables/DLL's than all later versions.

No!

All my projects have their DCU and build directories on a RAMdisk and I have specifically excluded this drive in the virus scanner. Using a RAMdisk has the advantage that it increases the lifespan of my SSD drive, my builds are crazy fast and the directory is guaranteed to be empty after each re-boot.

If any of the database components of your datamodule has a dependency on COM libraries (such as tADOconnection) you must do a coInitialize (inside the context of the thread) before creating the datamodule.

Use interfaces & tInterfacedObject. Put the interfaces like iVisitor, iDoor, iAutomobile etc in a common unit that contains no implementation code at all. The implementations+class factories should be in entirely different units that don't reference each other at all. Oh and instead of writing a big bunch of overloaded Visit() methods in a class, you could consider using a single method and use the "is" or the "supports" keyword if you really need to know the type of visitor.

How about "total mileage" (in the sense of Gesamtlaufleistung) ?

Is it a two-tier (multiple clients/one server) or three-tier system (with some middleware or website between the clients and the server)? In the first case, consider using a CTE (it runs atomically). In the latter case, consider using a mutex.

... anxiously awaiting 10.3.2 ....

I use form inheritance all the time. I have a base class that implements DPI Awareness on older Delphi versions (pre-XE10). From this, I inherited a new form class that handles multi-language (using dxGettext). And from this, I inherit a few form classes defining a consistent look-and-feel, like using my favorite font (Tahoma) and a top-aligned panel with our company logo.

Hello all, In a certain application of mine that contains a tDrawGrid, the program hangs if I drag the form between two screens with different resolutions. The program becomes totally unresponsive and I need to kill it with the task manager. This crash only happens if the grid contains a large number of rows and columns. It is compiled with Delphi Rio 10.3.1. I can work around it by setting the rowcount to a very small number immediately before the DPI change and then restore it afterwards. Kind regards, Arthur

Hi Dmitry, as far as I can see, the patch works!

Unfortunately tCustomgrid has no methods beginupdate / endupdate.

Done, https://quality.embarcadero.com/browse/RSP-24430

I have found the core of the issue. When a form receives a wm_dpichanged message, TCustomForm.WMDpiChanged is called which scales all components on the form. But TCustomGrid does it in a terrible way; there's this simple loop that modifies the heights of the rows: [vcl.grids, TCustomGrid.ChangeScale(), line 1735] for I := 0 to RowCount -1 do RowHeights := MulDiv(RowHeights, M, D); and in the debugger I see that this loop needs a whopping 72 seconds to complete on my Core i7 notebook (for 86400 rows). The reason? It appears that the changing of a single row height triggers an InvalidateGrid() plus an update of the scroll bars (which, incidentally, is why my breakpoints kept landing in USER32.SetScrollInfo). And all of this happens inside the handling of a wm_dpichanged message, so the message queue is blocked for ages which freezes my desktop.

When the freeze happens, all windows on the desktop (including the Delphi IDE) become unresponsive to mouse clicks and keyboard events. I need to press ctrl-alt-del to get into the task manager, only then am I able to set a breakpoint in the Delphi IDE. I managed to break into the main thread of the program and set a breakpoint there. The breakpoint itself is in GDI32.InternalDeleteDC() and the base of the call stack is in USER32.SetScrollInfo. Continuing the program then triggers the same breakpoint in an endless loop. If I simply remove the tDrawGrid from the form then the problem disappears and I can move the form between displays with different DPI without any freezing. If I set the grid's rowcount to a very low number, there is no problem either. My workaround for now is to temporarily set the rowcount to 1 just before the dpi change.

In the debugger I can break the program, but the current IP is always somewhere inside a Windows DLL and the call stack has no entries. I tried to make a reproducible test app, but no luck.

OK, so you guys use network mappings for just about everything. I know for a fact that in our own network some mappings often "hickup" and get disconnected for fractions of a second. This might be related to windows group policies being enforced in the background as suggested in this post https://social.technet.microsoft.com/Forums/en-US/5d9c7f34-5cf3-453a-a40a-3225e7995e9c/network-drive-keeps-loosing-connectivity?forum=win10itpronetworking but I don't know if the solution suggested in that thread actually works or not. As a workaround, would it be possible for you to ditch the "T:" mapping and instead use UNC names (\\server\sharename)?