Jump to content

David Heffernan

Members
  • Content Count

    3711
  • Joined

  • Last visited

  • Days Won

    185

Posts posted by David Heffernan


  1. 8 hours ago, Mike Torrettinni said:

    Yes, I guess this is how scroll messaging works, when pressing on scroll button:

    1. Scroll line down (button pressed)

    2. End scroll (button released)

     

    Which is probably fine for most applications, but I synchronize 3 or 4 scroll boxes at the same time and it was executing custom scroll 2x. So, annoying for anything that is customized, but I guess it is the right way.

     

    So, now I have:

     

    
    procedure TScrollBox.WMVScroll(var Message: TWMVScroll);
    begin
      inherited;
      if Message.ScrollCode <> SB_ENDSCROLL then
        if Assigned(FOnScrollVert) then  FOnScrollVert(Self);
    end;

     

    Until better solution comes along 🙂

    This looks badly wrong to me. What problem are you trying to fix?


  2. 30 minutes ago, Tommi Prami said:

    I clarify little.

    what mean by Default, not the Delphi default but MY DEFAULT what it ever would be. in current context.

    I also was thinking of using enumerated type or so, but it is not that official, Delphi defined way. Seems that this has not been thought at all while implementing this. There are ways around this, but seems no way to define some (random) defaulöt method parameter.

     

    -Tee-

    This provides no clarification to me. Now I think I have no idea what you are asking. 

    • Like 1

  3. 38 minutes ago, Tommi Prami said:

    Is there any standard way to pass encoding default

    You can't declare an encoding instance to be a default parameter value because it is not a constant, never mind a true constant. Hence the compiler error. 

     

    So you have to resort to overloaded methods. Declare one method that accepts an encoding parameter. And another that does not. From that second overload call the first passing your chosen default encoding. 

    • Like 1

  4. When the debugger evaluates some variables to display values in the debugger it often leaks memory. This is a defect with the debugger. The code here does not leak. Any reported leaks are due the debugger. 

     

    I see this very often with property getter functions that return strings. The debugger calls the function, creating a new string. But then the debugger fails to destroy the string. Leak. 


  5. 10 minutes ago, Mike Torrettinni said:

    I believe that my first projects accounted for 10% of world-wide AVs 🙂 Though, none of them corrupted any systems, disks, crashes... and no lawyers involved. I would not choose your security measures, but it is interesting approach.

    It is not interesting. 

     

    Also, no guarantee that invalid pointer leads to access violation. Corrupted data is perfectly possible. 


  6. 28 minutes ago, Attila Kovacs said:

    @David Heffernan I'm telling the same. The phrase you quoted was referring to the action "wiping a disk", if a "bug" could cause that, that bug doesn't have to be on purpose.

    There's a huge difference between making an unintended mistake after having done your best not to, and intentionally harming. It's surely not difficult to see. 


  7. 1 hour ago, Anders Melander said:

    I've used both VTune and AQTime with 64-bit projects and I can't recall that I had problems with it.

    What's your experience?

    VTune works well. AQTime was an unmitigated AV fest when I last tried it. 

    • Haha 2

  8. 2 hours ago, Alexander Halser said:

    Thank you! This has indeed solved the issue.

     

    
    initialization
      {$IFDEF WIN64}
      System.Math.SetExceptionMask(exAllArithmeticExceptions);
      {$ENDIF}

     

    Do this for both 32 and 64 bit. Just because you might get away with it in 32 bit for now, doesn't mean you always will. And if your app doesn't need floating point exceptions unmasked then mask them. Have consistency between 32 and 64 bit. 

     

    • Like 2

  9. Isn't this just the age old issue that Delphi's RTL unmasks floating point hardware exceptions, but most other tools (including the MS tools) mask them. So the ActiveX control that implements the embedded browser expects floating point hardware exceptions to be masked and is caught out by your host having unmasked them.

     

    Resolve the problem in the traditional way by masking floating point hardware exceptions.  There are countless SO posts on this subject which will show you how to do this.

    • Like 4
    • Thanks 1

  10. 8 minutes ago, David Schwartz said:

    @Kas Ob. it does not seem to make a difference. An AV is still happening. Maybe from something else.

    The code in the original post that uses SendMessage to send a string is correct. Your problem is elsewhere. A madExcept bug report at the point of the exception will tell you more. 


  11. 14 minutes ago, David Schwartz said:

    Well, there's a problem right off the bat. 

     

    
    procedure StatusOut(const stat: string);
    var
      AMsg:string;
    begin
      AMsg := UniqueString(stat);

    'stat' is a const arg, and UniqueString is looking for a 'var' arg.

    
    procedure UniqueString(var str: UnicodeString); overload;

     

    Perhaps the 'const' argument is part of the problem here?

    A big part of your problem is trying stuff at random without any understanding of the reason why. You say that you find windows a swampy mess, but the code you presented here can be reasoned with quite easily if one has the knowledge, and it isn't that advanced. Unfortunately quite aot of the "advice" you have received has been incorrect. 

     

    The only way for you to make progress is to stop guessing and trying random suggestions from people who don't understand the area. Get a stack trace with madExcept. It takes little time to add that. 

    • Like 1
    • Thanks 1

  12. Just now, Kas Ob. said:

    That doesn't answer the question about how many messages involved in adding text to a memo, are they guaranteed to be SendMessage or will involve PostMessage.

    It doesn't matter. The original call, made from the thread does not return until that message has been processed. If the code in the main thread, that processes the sent message, sends or posts messages, that's fine. 

     

    I don't think that we should hijack this thread anymore. 

×