Leaderboard

In addition the LSP can run as a background thread parsing while you type and then providing the results asynchronously.

Unified memory management only affects mobile compilers and if you are developing for Android you will have to use 10.4. Developers developing for iOS will still be able to use 10.3.2 for a while, but probably not for too long... and even for them it would be smart to switch to 10.4 as soon as possible to adjust their codebases. As far as LSP is concerned... code completion and navigation as well as code insight is pretty much broken as-is... I cannot imagine LSP in its first release being so bad that it would justify staying at 10.3.2. Also 10.3.2 and 10.4 can live side by side... so you can have both and use version that is more appropriate for any particular reason you may have.

I'm guessing sometime close to next Wednesday: http://blog.marcocantu.com/blog/2019-july-whatsnew-1032-webinar.html

Instead of building separate executables, I suggest building one executable and leveraging feature toggles through licensing schemes or phone-home type methods

While working on a tool for cleaning up uses clauses I stumbled upon this beast (slightly changed to protect the innocent): {$if defined(DEBUG) or defined(DEBUG_SPECIAL)} uses {$ifend} {$IFDEF DEBUG} dialogs {$ENDIF} //<some comment about the following ifdef> {$IFDEF DEBUG_SPECIAL} mmsystem, // timeGetTime() messages {$ENDIF} {$if defined(DEBUG) or defined(DEBUG_SPECIAL)} ; {$ifend} If you are only looking for uses clauses inside some Delphi sources and try to avoid a full featured parser, you will have a pretty hard job to detect, parse and interpret that one correctly. So, if you are interested to make any use of such a tool, please do me a favor: Don't write your code that way! It is hard to read for humans anyway.

More like this Thursday https://community.idera.com/developer-tools/b/blog/posts/announcing-the-release-of-delphi-c-builder-and-rad-studio-10-3-2

So the call gives a TWRC_XFERDONE (successful) but the handle could still be invalid. The handle (hNative) is a TW_UINT32 (which is a Cardinal/32bit). I wonder if it shouldn't be a TW_Handle (which should be a NativeUInt and UInt64 on 64 bit). At least GlobalLock expects a THandle (which is UInt64 on 64 bit). Doesn't seem really wise to stuff a handle in an Cardinal/32bit on 64 bit (which like David already mentioned, could be just a simple 32/64 bit truncation error). Strange this worked locally on the machine itself but fails on RDP. Maybe the handle-numbers are much larger and it fails.

With LSP the same parser can be used for IDE and compiler. Now they're completely different.

The TOSDevice record in this unit: https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.OSDevice.pas Has a ShowFilesInFolder method, which "re-routes" to the respective platforms, namely macOS and Windows. For macOS: https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.OSDevice.Mac.pas For Windows: https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.OSDevice.Win.pas

It is never a good ideal in high performance application to update a visual component like TMemo, scrolling the screen is expensive for heavy updates and will slow down or even stall your application, likewise calling Synchronous to do that stops your thread. I've been slowly updating ICS samples like OverbyteIcsIpStmLogTst1.pas so that log lines build a string buffer which is written to a TMeno from a timer every one or two seconds which is fine for most purposes. It is better to use Windows messages or even a socket to send logging to the main thread, effectively they become a non-blocking queue. Our tests with ICS indicate a single thread will handle at least two hundred simultaneous requests, provided don't block with SQL or start doing massive MD5sums or other horrible stuff. If you look at the OverbyteIcsMailQueue.pas unit, that has a thread to send emails from a queue, updating by the main thread, and shows how to use a message handler while the thread is waiting to do something. However if your thread only makes continual sync Post requests, you might get away without a specific message handler because ICS calls one itself waiting for the request to finish. But I'd still suggest creating an array of 10, 50, etc, TSslHttpCli all sharing the same event handlers, use Tag to identify which is calling an event and test that. This just works. Angus

Webinar: What’s New in Delphi, C++Builder, and RAD Studio 10.3.2? https://community.idera.com/developer-tools/b/blog/posts/what-s-new-in-delphi-10-3-2-webinar-next-week http://s608.t.en25.com/e/es?s=608&amp;e=3212415&amp;elqTrackId=65d0dc3c5cdd4756be52277591b686f0&amp;elq=c25618b1ac194292a576b4839d8d5592&amp;elqaid=31246&amp;elqat=1 Presenters: The Embarcadero Product Management Team - Sarina DuPont, Marco Cantu, and David MillingtonSession: Wednesday, Jul 24, 2019, 8:00 AM - 9:00 AM CST Join the Embarcadero Product Management Team to discover new capabilities throughout Delphi, C++Builder, and RAD Studio designed to delight Delphi multi-device developers and C++ Windows Developers. https://register.gotowebinar.com/register/1262173778065437955

Actually, a manual critical section is not good enough, because behind the scenes the main UI thread will periodically reach inside any TCanvas objects that are not locked via their Lock() method. A manual critical section will not prevent that, you have to use the critical section that TCanvas.Lock() uses internally.