Jump to content

dormky

Members
  • Content Count

    142
  • Joined

  • Last visited

Community Reputation

4 Neutral

Recent Profile Visitors

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

  1. dormky

    Suggestions for new vendor of a delphi app?

    If you're open-source, you need to sell something else (training, resources, support, etc...)
  2. I'm 100% agreeing with you. Management doesn't. Management wants a pretty loading icon without actually putting in the work 🙂 Imo the windows cursor does a perfectly fine job, we're talking ~10s loading time here.
  3. I thought about this, but dismissed the idea as this would mean the loading gif is dissociated from the window in which the loading occurs. If the window gets resized, moved, minimized or simply if the user opens up another program in that screen space that form is in trouble (ie will not be kept visible only when the working window is visible, and centered within it).
  4. Going around a bunch of files inserting calls to ProcessMessages in mostly random places (the work is not deterministic) seems like a magnificient way of shooting both feet at the same time 😕
  5. I've tried calling Application.ProcessMessages from a thread, that didn't work. Had to try it lol. My goal is to have a loading gif playing while the work is ongoing. The work cannot be moved out of the main thread, as this would require rewriting multiple thousands of lines of code, which is sure to create bugs (especially as this deals with COM ports). Any ideas ?
  6. dormky

    Introducing TRange<T>

    For most cases, I would recommend using the delphi-provided libraries instead of rolling your own, see https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Math.InRange
  7. To note ; the OnFormClose event isn't called when calling Close. However I just discovered there is a CloseModal function, which doesn't set the ModalResult to cancel in the case where the form is modal. It does set ModalResult to 0 in the case where the Action is set to caNone. Again, just a badly designed API. OnFormClose should be called no matter how you close the form. There shouldn't be 3 separates ways of closing the form, there should be one (taking arguments if you do want to manipulate some behavior). And said way should not be manipulating the value I want to return to the caller, as that is app data. This is like having 3 locks on your door, each looking the door in a different way and you can only lock one at a time. Also the second and third lock each turn on a different porch light when you use them after 22:00.
  8. Sure, and using assembly is logically identical to using C. But for the vast majority of purposes one has a better API wouldn't you say ? Bit of an overkill comparison, but the point stand. The Windows API in this case is better than the Delphi one for reasons already outlined.
  9. If they implemented it in the same way (a single flag serving two purposes), I would levy the same critique. With the caveat that it least it doesn't make the API more confusing since it's internal. Whereas as far as I'm aware, Delphi had no obligation to implement it in the same way, although it might have been a volition at the time to do a one-to-one of Windows. Which could be critiqued in itself, of course.
  10. Yes, and I established that it does it _internally_ and that you don't have a single flag serving two purposes, as you do in Delphi.
  11. Depends on the project of course, and secondarily on my current skillset. For the project that spawned this thread, I probably would have gone with WPF, which would have given me easy access to the .NET ecosystem which would be useful since there's a lot of places with custom drawing, while the rest of the interface is very basic.
  12. Of course, I never would have chosen Delphi for a new project. But there's a lot of old 90's projects out there for which it's not cost-effective to move to a more efficient platform, so Delphi sticks around.
  13. By implementing your own ShowModal which doesn't rely on it and instead listens for a "close" event, I suppose. Maybe you could make a "Close" function which would raise this event and set the return value to the value given by argument... You know, just how EndDialog does it 😉
  14. Hey, bad design doesn't mean it's not useful. I still use a car whose AC is less powerful then a fart lol.
  15. Yes, but the difference is that the flag is internal. We do not have access to it, nor is it the same as the value returned by ShowModal call. Again, to close in Windows I call function. In Delphi I set a flag. Fundamentally different things.
×