Tom F

Yes, it's the old TurboPower profiler. The UI didn't bother me. No doubt it could be improved, but I found it easy to understand and get my work done.

I used AQTime for many years, but it seemed to me that SmartBear wasn't really interested in the Delphi market and their product suffered ... and was expensive. I more recently purchased Nexus Quality Suite and was very happy with it. Great tool, great support, great modern product: https://www.nexusdb.com/support/index.php?q=node/27156. As someone previously said, "You get what you pay for." NQS was well worth what we paid for it.

Bill, not to start a flame war, but I love the trailing comment on procedures: procedure SomeOp; begin end; { SomeOp } Why? Because when I'm scrolling up from the bottom of a unit, when a procedure's end; statement comes into view, I can immediately identify the procedure without having to scroll up further. As you say, the IDE does not strip empty procedures that have a comment like this. But, IMO, that's a small price to pay. What does bug me is that when I use Shift_Ctrl-C, the IDE puts new methods between the end; and the comment. But even with that hassle, I still prefer the comment.

Is there a VCL component (preferably included in the current Delphi) that shows a grid of items that automatically adds and removes columns as it's resized? I want to show items in alphabetical order across each row, as shown below. (Horizontal snaking) As the grid is resized (when the user resizes its form), I want the grid to automatically add more columns, repopulating as shown below. I know I could populate a TStringGrid, but I'd have to monitor the current width, determine how many columns it can accommodate, resize the grid and then repopulate, etc. Rather than re-inventing the wheel (mine would be wobbly and squeak!) I'd rather just hand a TStringList to a pre-existing visual component and have it handle the details. In case I want to create my own from a TStringGrid, the OnResize event fires multiple times as a user drags the borders of the form. How do I detect that the user has finished resizing so I can repopulate the grid? Three columns A B C D E F G H I When the user widens the form so that it's wide enough for five columns, it would look like this: Five Columns A B C D E F G H I One Column A B C C D F G H I

Thanks, Anders. The List-View control works great for my purposes. THANKS!!

I'm planning to approach the author of another program that captures video data. I'm going to ask her to team up with me, sending the video frames that she's capturing in realtime to my 32-bit Delphi Rio VCL app running at the same time. Her app is probably written in C# or C++. The data will be video frames and maybe 10 or 15 megs each, 30 fps. I don't mind dropping frames so I don't need more than one memory buffer. I don't want her app to block if my app is too busy to pick up his data. In other words, if she has a frame to send and I'm in the process of reading his data from shared memory, he can just skip sending me that frame. Basically, I want some way she can fill a memory buffer and then signal me it's ready. I'd receive a Windows message and read the buffer. She and I would clearly need some locking semaphores so we can access the data safely. And there will be some messaging necessary at startup and shutdown. And I need to have a way of rapidly copying the buffer she provides into a variable in my app. I'd like to propose to her a reliable mechanism that's simple for both of us to implement. I'm okay using third-party tools if necessary for my end (in Delphi) for handshaking and messaging and data transfer. I don't know much about interprocess communication, so I don't know what issues or tools I should be looking at. I've thought a bit about some semaphores and shared memory and PostMessage notifications between our programs, but I don't have any experience in them or other similar tools. About all I know about these types of systems is that they can dramatically fail in unpredictable ways and that they're hard to do right. 😞 I, of course, don't want to re-invent the wheel, so I'm asking here: Can anyone give me suggestions on how to approach this?

When a user clicks on the TImage below, I want to know which arrow, if any, they've clicked on. The image is loaded in Image1.Picture from a bmp that is loaded at runtime. The code below works on my desktop machine, but not on a laptop, where it most often returns 'You did not click on an arrow.' Perhaps this is due to dependencies on screen size, resolution, color depth, or ??? I'm not really familiar with how HDC, GetCursorPos, and GetPixel work let alone in different environments. Any suggestions for a way to reliably detect which arrow is clicked. 32-bit VCL app. Procedure TForm1.Image1Click(Sender: TObject); const COLOR_VIOLET = 4002090; // Determined empirically by examining at result of GetPixel call below COLOR_PURPLE = 8334696; COLOR_BLUE = 11757312; COLOR_GREEN = 7186176; COLOR_RED = 255; var P: TPoint; dc: HDC; ClickedColor: TColor; begin GetCursorPos(P); dc := GetDC(0); ClickedColor := GetPixel(dc, P.X, P.Y); if (ClickedColor = COLOR_VIOLET) then ShowMessage('Violet') else if (ClickedColor = COLOR_PURPLE) then ShowMessage('Purple') else if (ClickedColor = COLOR_BLUE) then ShowMessage('Blue') else if (ClickedColor = COLOR_GREEN) then ShowMessage('Green') else if (ClickedColor = COLOR_RED) then ShowMessage('Red') else ShowMessage('You did not click on an arrow.') end;

ScreenToClient was what I needed. Thanks!

Last year, on Sierra, I was able to run debug my FMX app on a Mac mini (Late 2014, 1.4 i5, 4 GB, SATA) from my Win10 machine. On Catalina, that this machine is almost unusable as a standalone Mac (which isn't a Delphi issue). Running from Delphi 10.3.3 is painful. My app has a small footprint (in CPU and RAM). I'm planning on getting a 3.6GHz i3 MacMini with 8 gigs RAM and SSD. Any feedback or suggestions on this choice?

Thanks, Graham. Helpful information. I decided to upgrade to a 2018 Mac Mini with SSD. Apple makes it too easy to spend money here in Seattle. I ordered it online at 9 am. It was delivered to my front door by courier (at no charge) 90 minutes later! Amazing. While preparing the old 2014 Mac mini to sell, I cleaned the machine and reinstalled Catalina, thinking that perhaps there was something misconfigured. But, no: it was as slow on the clean install as it had been previously.

Is it possible to suppress the display of lines in the debugger's Call Stack that are not in my source? For example: VCL, Kernel, etc. I don't want to see the highlighted lines.

Hi, Dany, No, please don't keep quiet! I appreciate your insight. And it's interesting to me how in your and others' experience, seeing the call stack in the debugger into the RTL is important. My experience is different from yours. I've managed over 1.5 million lines of code over more than a decade. And I've never once encountered an RTL bug. Of course, years and LOC don't prove anything. I mean, maybe the code is trivial and braindead and doesn't do anything that might encounter a bug. Maybe I'd be more informed and a better programmer if I traced into the RTL more often and studied its code. Maybe because I don't do that, I'm really not using the RTL and VCL as effectively as I might. There's no way to know, but I'd think that (in spite of lots of complaints we see online) the majority of Delphi users have never encountered an RTL bug. At least I hope that's true! 🙂 But, maybe I'm wrong. Anyway. I'm not intending to be combative. I just know that my preference would be not to see the RTL in the debugger call stack. It sounds like that's not going to happen, so I'll just have to scroll the stack view in the debugger more often and learn to ignore entries that AFAIK I don't need to see. Thanks again for sharing your experience. I'd be interested in hearing what others have to say about this. But, not in an adversarial way, but because I genuinely wonder how often the RTL stack is important in day to day use.

Hi, Uwe, Actually, I'd find it quite useful to remove VCL entries from the display of the call stack in the debugger. If the call stack is "cluttered" with a lot of VCL entries, it makes visually scanning it more work and may introduce the need to scroll the list. Although there are times that seeing how the VCL is being used might be helpful, most of the time many of us are only interested in our code, not the VCL. Anyway, from the responses I got here, it seems like hiding the VCL in the call stack in the debugger isn't something that can be easily done, if done at all. Thanks for your comment. Tom

Hey, I'm far, far from an expert on these matters so my thinking may be very flawed here. But when app #2 gains focus, perhaps it could send a message (and wait for a response) to app #1 telling it to de-register the hotkey? And then app #2 registers the hot key. And same for when app #1 gains focus, it messages and waits for app #2 to de-register the hotkey.

Not cross platform, but this might interest you: JCLSYSUTILS.Execute().

Can you provide the names of those groups?

The recent GetIt failure has exposed some vulnerabilities many of us have in archiving our development machines. Using local backup procedures and virtual machines to archive our development machines is one way we can protect ourselves. But, another reasonable safeguard would be for us to assure that we can build our development environment from scratch, offline. Archiving the RAD Studio ISO is a good first step. But, if the GetIt servers are down, or if older versions of tools become unavailable for any other reason, the ISO is insufficient protection. Perhaps we can archive GetIt installers also? Marco's post (from last year) indicates that the IDE can create an html log of GetIt actions: http://blog.marcocantu.com/blog/2018-july-getit-install-logs.html. Examining the sample logs in his blog, it appears that C:\Users\Public\Documents\Embarcadero\Studio\20.0\CatalogRepository\ might contain the downloaded installers that we could invoke using the command lines that are in the log. I plan to empirically test this approach, but thought I'd ask the expert community here for any insight or experience it has on this. Has anyone here ever tried to manually install GetIt downloads by examining this log and using command lines with the .exe files? Are there any rules about GetIt downloads being self-contained, or perhaps might they also download additional resources.

EMB has provided a temporary GetIt until their main servers are back up: https://community.idera.com/developer-tools/b/blog/posts/temporary-10-3-2-getit-server-for-installing-10-3-2-add-on-packages

EMB has provided a GetIt work-around: https://community.idera.com/developer-tools/b/blog/posts/temporary-10-3-2-getit-server-for-installing-10-3-2-add-on-packages

I agree. And although I have the RAD Studio ISO, I'm unable to do any work on our code base until I can get a copy of the Konopka (nee Raize) components installed. Which, of course, depends on Getit. The above was the reason for my OP. I haven't found any way to purchase source for the library (nor do I want to spend the money.) I plan to explore grabbing the installer from the CatalogRepository folder once Getit is running again. Although this will be "closing the barn door after the horse has escaped" at least I'll be protected should this total failure by EMB happen in the future.

David, Can you be more clear why you're saying that? Is the test he's doing not reliable, or are you simply saying if the test succeeds, the server may come back up during the interval between the test and the email send.

I'm able to build 64-bit apps for the Mac! I'm not an authority, so I'm not sure if this workaround helps: If macOS 64-bit doesn't show up under Target Platforms, try editing the .dproj file in a text editor to make sure it has an OSX64 line like the underlined one below. <Platforms> <Platform value="Android">False</Platform> <Platform value="iOSDevice32">False</Platform> <Platform value="iOSDevice64">False</Platform> <Platform value="iOSSimulator">False</Platform> <Platform value="OSX32">True</Platform> <Platform value="OSX64">True</Platform> <Platform value="Win32">True</Platform> <Platform value="Win64">False</Platform> </Platforms>

You might want to do a survey to confirm your speculation on how many developers are still on 32-bit vs 64-bit. I'd be surprised if even 25% of Delphi users are on 64-bit.

Mostly on-topic question: how is it that commercial remote control programs (Zoom, GotoMyPC, WebEx) seem to be able to get around most firewalls without help from IT?

We have a stable shipping MacOS product (50,000 LOC) that we developed over the past few years with RAD Studio 10.2 Update 3 and MacOS Sierra (10.12.4). It was originally written for the VCL ten years ago. We continue to develop the VCL version, but share a lot of non-UI code with the FMX version. For our needs, cross-platform development with RAD Studio has worked wonderfully. We thought now would be a good time update to Mojave on the Macs to make sure our products remain current. Frankly, the cross-platform tools have (thankfully) hidden what goes on behind the scenes, so I haven't had to learn anything about Xcode, etc. Thus this question: I know there are no guarantees, but should I expect RAD Studio 10.2.3 work with the Mojave (and XCode 9.2 that it installs?) Perhaps I'll just have to redeploy the PAServer? Or will I have to upgrade to Rio? We have a full subscription to Rio, but even after the recent update, for it, we're still quite nervous about making the jump from Tokyo to Rio. The few 3rd party add-ins that we use are available in Rio. However, having seen the problems that some forum members here have reported, we're hesitant to upgrade to Rio. One other comment: if EMB fails to deliver in a timely manner a viable version that allows us to create 64 bit Mac apps, we'll be really, REALLY unhappy that we'll be unable to ship our product. Hopefully, Macro and others at EMB are listening and understand how critical this capability is for those of us who trusted EMB by chosing to build MacOS apps with RAD Studio. I hope that our trust wasn't misplaced.