Jump to content

dummzeuch

Members
  • Content Count

    2637
  • Joined

  • Last visited

  • Days Won

    91

Posts posted by dummzeuch


  1. I my opinion Delphi 12 + Update 1 is a little bit more stable than Delphi 11 + Update 3.

     

    But I am not using either very much due to the (IDE) annoyances when mixing HighDPI monitors and non-HighDPI monitors, so I'm not an authorative source for such a comparison.


  2. 3 hours ago, maths bengtsson said:

    Is there a way to declare dbugintf .pas'  in just one place  instead in  every units  I want to use senddebug for instance

    If by "declare" you mean "add to the uses list": No that I am aware of.

     

    In theory you could add the code into an existing unit that's already in the uses clause everywhere. You could create lightweight wrapper functions that get exported from that unit and simply call the original functions in dbugintf, thus basically redirecting the calls.

    Depending on what you want to do that might work for you.

    • Like 1

  3. 1 hour ago, Sherlock said:

    The certificate is there to show that someone feels responsible for this file. And is confident enough to stick his name to it. Since then it has not been altered.

    ... and cares enough, to spent some significant amount of money and lately effort on buying and using one.

    • Like 1

  4. I just extended my dzDebugVisualizer package to include a TColor debug visualizer for Delphi 10.2 and Delphi 12. With little change these will probably work for every Delphi Version that supports the neccessary ToolsApi functions, meaning >= Delphi 2010.

    This is completely different code than I used before, but it still shows the color name(s) and the RGB value rather than the integer value.

     

    read on in the blog post

    • Thanks 3

  5. 2 hours ago, David Heffernan said:

    I don't really follow this. If you have to modify your code to add the message dialog, before you start debugging, then I'm not quite sure why you can't run with a debugger attached. If you are happy to attach the debugger later, why can't you attach it at the start?

    1. When run in the debugger, the IDE sits in the taskbar and I might accidentally bring it into the foreground while I am working on something else in a different IDE instance (or any other program). No big deal but it always interrupts what I am currently doing. But if I am working in a different instance of the IDE I might accidentally change the source code or even worse terminate the debugging without noticing that I am in the wrong IDE instance. This has happened more often than I would like to admit.
    2. Any kind of exception will stop the program while running in the debugger, even if there is a handler for it, and bring the IDE to the foreground. I then have to check whether I am interested in it or not. Again, just an annoyance. I could probably turn off "break on exception" for that, but I tend to forget changing this back, in particular if I am working on a different program in a different instance of the same IDE.
    3. Sometimes it takes quite a while for the situation I am interested in to occur (we are doing a lot of batch processing on large database files that might run for hours and I might not know what causes the problem so I can't run it on a smaller database), so the program might run over night with nobody there to press the "Run" button if that happens.

  6. 3 hours ago, David Heffernan said:

    If you are debugging then throwing an exception is the way to do it. Then the debugger freezes all threads. You surely don't want the other threads to continue running at this point.

    As I originally said: It depends on the use case.

     

    My programs usually have only the main thread for the UI and possibly one or (very rarely more) worker threads that are independent of each other (no threadpool). In that case it does not matter whether the other threads continue to run or not.

    An exception won't work because I only use this method when I don't want to run the executable inside the debugger in the first place, so there won't be a dubugger to catch that exception.


  7. 15 hours ago, DelphiUdIT said:

    May be is related to this https://docwiki.embarcadero.com/RADStudio/Sydney/en/Visualizers but I don't think that there are the source code available.

     

    There is a ToolsApi about that: https://docwiki.embarcadero.com/RADStudio/Athens/en/Debugger_Visualizers

    I had already found these but the description was not really helpful in creating one. For me nothing beats a good example when trying to understand some API.

     

    There is also an example of a TColor debug visializer by Linas Naginionis on Medium with a link to source code that no longer works.

    and possibly the same code on GitHub.

     

    And I just stumbled upon something called GenericVisualizer by Alessandro Fragnani, also on GitHub.


  8. 13 hours ago, Darian Miller said:

    There is source in the Visualizers folder:

     

    Embarcadero\Studio\23.0\source\Visualizers

     

    It doesn't include the .dpk though.

    Thanks a lot. That the samplevisualizers.dpk is missing also explains why my search didn't turn up anything.

    (Just in case anybody else is looking: It's inside the Delphi installation directory, not in Public Documents.)


  9. 6 hours ago, Remy Lebeau said:

    If the code is expecting a debugger to attach, I would just call IsDebuggerPresent() in a sleep loop until it returns true or times out.

    There are two reasons for displaying the message:

    1. Stop the thread at that point
    2. Inform me that the situation I want to have a closer look at has occurred

    It's a simple way to do that when this situation happens irregularly and I don't want to run the executable in the debugger from the start. Yes, it could be differently, but I don't see the point to make it more complex than necessary.

     

    As for David Heffernan's  comment: I'm talking about debugging, not production code. I thought that was clear from the context.


  10. There is a package installed in the IDE called "Embarcadero Sample Debugger Visualizers" (package name is: samplevisualizers). Given it's called a sample, I would have expected that the source code is also available, but I can't find it, neither in my Delphi installation(s) nor on Embarcadero's Gitub Sample repository. Any hints?


  11. 11 hours ago, David Heffernan said:

    Reporting error dialogs from thread pool threads sounds terrible. Stop doing it at all and then you don't need to think that one message box function is better than any other. 

    That depends on the use case. If you want to show the error in order to then connect the debugger to the running executable, that's a good way to do it.


  12. I have just built an installer for GExperts 1.3.24 Beta1 for Delphi 12. Note the word “Beta” in the release name! We are one step up from Alpha, there are still many bugs, but overall it seems to be stable. Most of the bugs manifest themselves as display glitches on high DPI monitors.

     

    Continue reading in the blog post

    • Like 5
    • Thanks 5

  13. 7 hours ago, Lars Fosdal said:

    3/4. Why not simply use GExperts?

    Simle answer: Because GExperts has fallen behind in quality and update frequency since it has become a one man show (me).

    There is only an Alpha release availabled for Delphi 12 and that one contains many bugs. Some of these bugs have been fixed, but in order to get these fixes, you need get the sources and compile your own dll.

     

    Edit: I just took this as an opportunity to release a new Beta version for Delphi 12. But I'm still trying to catch up with High DPI.


  14. 1 hour ago, Brandon Staggs said:

    That is not correct. DPIv2 allows exactly that, and that is when Embarcadero added this option, and I vaguely recall testing it to satisfaction on my Surface Laptop. I have not returned to that to look at it since, though, as I don't do any real dev work there.

     

    https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows?redirectedfrom=MSDN#mixed-mode-dpi-scaling-sub-process-dpi-scaling

     

    https://learn.microsoft.com/en-us/windows/desktop/api/Winuser/nf-winuser-setthreaddpiawarenesscontext

     

    It is entirely possible that Delphi does not do it this way and I am mistaken. I can't really remember. I think I might check, out of curiosity.

    SetThreadDpiAwarenessContext is exactly the API call I tried to use back then. I couldn't get it to work. Mostly probably because as an IDE plugin GExperts does not have any control over the API calls in other parts of the IDE. I spent several weekends trying to get this to work and then I gave up.


  15. There is a bug report on this (at least one). I even used one of my support tickets for this but Embarcadero could not help me. That was back, when Delphi 10.2 was the latest and greatest version. If I remember correctly they are looking into the wrong registry branch, so the fix should be easy (but maybe I'm overlooking something). I was lucky in so far as it turned out I didn't need to use an assembly after all.


  16. 2 minutes ago, Brandon Staggs said:

    I don't know why I was thinking it just let Windows scale the output (ie, the window is treated as DPI unaware). Obviously I agree that editing the form that way is very suboptimal.

    As far as I know you cannot set a single window to DPI unaware and have the rest of the program be DPI aware. I tried that with GExperts because I didn't want the hassle of making all Windows scale correctly (especially because that was buggy as h**l with Delphi 11.0). I failed miserably. But maybe that's just me.


  17. 3 minutes ago, PeterPanettone said:

    Have you really asked an AI for a bike rental? Are you serious?

    Yes, why shouldn't I? I could have googled it myself, but since AIs are soooo great and Google had just sent me an email saying so, I tried it. And it failed as I expected. To be fair: The list contained other entries that seemed to be valid.

    I told it that this one entry was wrong and it - with the usual "I'm sorry ..." bla bla - gave me a new list ... which contained the same wrong entry again.

    Guess who was impressed? Me neither.


  18. 1 hour ago, PeterPanettone said:

    Low-quality AI answers often are the result of poor prompts.

    Example (Gemini) (asked in German, Translation see below):

    Frage: "Welche Fahrradverleihe gibt es in Braunsbedra?"

    Die Antwort enthielt unter anderem einen Fahrradverleih in Ostfriesland.

    (Braunsbedra ist eine Stadt in Sachsen-Anhalt, am Geiseltalsee, > 400 km von Ostfriesland entfernt.)

     

    If that's a poor prompt, I don't know what a good  one should be. And I have had similar experiences with ChatGPT.

     

    Translation:

    Question: "Which bicycle hire companies are there in Braunsbedra?"

    The answer contained one from Ostfriesland.

    (Braunsbedra is a town in eastern Germany, at the Geiseltalsee (lake), > 400 km from Ostfriesland (north sea shore))

     

     

    • Haha 2
×