Jump to content

Tom F

  • Content Count

  • Joined

  • Last visited

Community Reputation

7 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. 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;
  3. Tom F

    Mac specs for development

    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.
  4. 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?
  5. 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.
  6. 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
  7. 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.
  8. Tom F

    Scope of a HotKey??

    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.
  9. Tom F

    How to know that a file is not used by another program?

    Not cross platform, but this might interest you: JCLSYSUTILS.Execute().
  10. Can you provide the names of those groups?
  11. 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
  12. Tom F

    GetIt work-around

    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
  13. 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.
  14. 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.