Jump to content

Anders Melander

Members
  • Content Count

    2265
  • Joined

  • Last visited

  • Days Won

    117

Posts posted by Anders Melander


  1. Try this then:

    type
      TMyForm = ...
      private
        FUpdateCount: integer;
        FLockedHandle: HWND;
      end;
    
    procedure TMyForm.BeginUpdate;
    begin
      Inc(FUpdateCount);
      if (FUpdateCount = 1) then
      begin
        FLockedHandle := Handle;
        SendMessage(FLockedHandle, WM_SETREDRAW, Ord(False), 0);
      end;
    end;
    
    
    procedure TMyForm.EndUpdate;
    begin
      Dec(FUpdateCount);
      if (FUpdateCount = 0) and (FLockedHandle = Handle) then
      begin
        SendMessage(FLockedHandle, WM_SETREDRAW, Ord(True), 0);
        RedrawWindow(FLockedHandle, nil, 0, RDW_FRAME or RDW_INVALIDATE or RDW_ALLCHILDREN);
      end;
    end;

     


  2. 7 minutes ago, Attila Kovacs said:

    It's just a silly app limitation disabling compression for lower res.

    It's not silly; It's for backward compatibility.

    Since the ICO format originally didn't support PNG compression, using compression for icons smaller that 256x256 will break any application (including Windows) that was written before PNG support was introduced. Using it for icons of larger sizes is relatively safe since these sizes should be ignored by older applications (and OSs).


  3. 1 minute ago, Cristian Peța said:

    It's for buttons and menu items.

    I think the question (and my answer) is specifically about what TForm.Action is for. Not what TControl.Action in general is for.

     

    The Action property is explicitly published by TForm so it's not by accident that it's visible in the property inspector.

    • Like 1

  4. I don't ever use the OnExecute handler, but I generally use the OnUpdate handler to update controls that does not support actions themselves.

    I guess one could also use it to control TForm.Enabled but I've never had a need for that.

     

    The forms OnUpdate handler is also convenient when modernizing applications that were written without TActionList. These tend to have a single method that contains all the UI update logic. I move this logic into the OnUpdate handler, review and remove all the calls to the old update method and then start migrating the logic to individual actions. I mostly end up with some logic that can't be handled by actions and so it stays on the forms OnUpdate handler.

    • Like 1

  5. This works for me:

    function DetectRemoteSession: boolean;
    const
      SM_REMOTECONTROL      = $2001; // This system metric is used in a Terminal
                                     // Services environment. Its value is nonzero
                                     // if the current session is remotely
                                     // controlled; otherwise, 0.
    
      SM_REMOTESESSION      = $1000; // This system metric is used in a Terminal
                                     // Services environment. If the calling process
                                     // is associated with a Terminal Services
                                     // client session, the return value is nonzero.
                                     // If the calling process is associated with
                                     // the Terminal Server console session, the
                                     // return value is 0. The console session is
                                     // not necessarily the physical console.
    var
      Mode: string;
    begin
      Result := (GetSystemMetrics(SM_REMOTESESSION) <> 0) or (GetSystemMetrics(SM_REMOTECONTROL) <> 0);
    
      // Test for emulated local/remote mode
      if (FindCmdLineSwitchEx('Session', Mode, ['-','\','/'], True)) then
      begin
        if (SameText(Mode, 'Remote')) then
          Result := True
        else
        if (SameText(Mode, 'Local')) then
          Result := False;
      end;
    end;

     

    • Thanks 1

  6. I see you're using MadExcept. Are you aware that it has built in leak detection?

     

    I don't know deleaker but it might be that it can't track cross thread allocations/deallocations. I know some leak detection tools has problems with that.


  7. So basically a suite of Delphi components that wraps some .NET controls which wraps the exact same Win32 controls that the corresponding VCL wraps...?

     

    Maybe you should move your post to the Third-Party group.


  8. Explorer (e.g. the desktop) supports FileContents/FileGroupDescriptor and many other application does as well.

     

    If your files are mostly virtual (i.e. they are generated from a database or the like) and are only saved to disk in order to be able to drag them, then FileContents/FileGroupDescriptor is actually the right choice. In that case make FileContents/FileGroupDescriptor your primary format and only write the data to disk if the drop target requests CF_HDROP/Filename.

    • Like 1

  9. I just realized that I've already released a newer version of the tracer. It's in the Demos folder:

    https://github.com/DelphiPraxis/The-Drag-and-Drop-Component-Suite-for-Delphi/tree/master/Demos/TargetAnalyzer

    It lacks the ability to save the trace though.

     

    Everything appears fine judging from the trace; The drop targets (I'm assuming you dragged across some other drop targets before you dropped on Outlook) queries for various formats during the drag and after the drop the target (Outlook) asks for the "Filename" and CF_HDROP formats.

     

    My guess was initially that there either something wrong with the particular file you're dragging which caused Outlook to reject it or that the data returned by the drop source was corrupted somehow (you could use the SourceAnalyzer demo to check the data). But then I found this:

     

    Drag & Drop files from 32bit winforms application to 64bit Outlook

     

    TLDR; It appears to be a known problem in Windows which apparently hasn't been fixed yet.

    According to one of the comments a possible solution is to use the FileContents and FileGroupDescriptor formats instead.
    See the VirtualFile, VirtualFileStream, SyncSource and AsyncSource with Filestreams demos for examples of how to do that. AFAIR you can add these formats to your existing drop source with an Adapter, but I can't remember how to do that. There's probably a demo about it.

     

    Here's another thread about the problem but here they don't seem to have realized it's a 32/64 bit issue:

    Issue with file drag/drop to Outlook in Windows 10

    • Like 1

  10. FWIW, the Drop Source Analyzer demo from The Drag and Drop Component Suite does pretty much the same as InsideClipboard.

    image.thumb.png.c55308287808be8f2ae6875c03977c58.png

    WRT you problem my guess is that GExperts uses some RTF codes or line delimiters that your target doesn't support.

    Try pasting via WordPad or a plain RichEdit control instead. They probably don't mess as much with the RTF as Word does.


  11. I use the policy that all projects must be completely self-contained.

     

    Each project has a complete copy (source and installer) of the all the in-house and third party libraries used.

    The project search path points to the local copies.

    I always build from the source.

    dcu, exe and bpl files goes into local project folders.

    Everything is under version control.

     

    Getting a project setup on a new system is just a matter of fetching the project from version control, running any necessary 3rd party installers (usually just for design time functionality) and installing the bpls. Since the different projects tend to use the same libraries the two last steps are usually just done once.

     

    I don't care about what the installers do because I don't use their dcu-files or their search paths. The project itself contains it all.

     

    Never had problems with duplicate dcus (since I started doing it this way, that is).

     

    There's of course the problem that different projects might use different versions of design-time components, but that is a bit outside the scope of your question.

     

    WRT the VM solution I used it a while ago and it actually worked very well. I used Hyper-V with one VM per project. The only problem was that it got a bit tiresome to have to install the same tools in each and every VM whenever there was a change in the toolset.

    • Like 1

  12. 41 minutes ago, Stefan Glienke said:

    Those horrors would not be worse than half a mile of if-then-else-if "ladders".

    True.

    I'm more worried about those that would use something like this just because it's a new smart way of doing stuff, regardless of whether it's a suitable pattern to use - and then I have to clean up after them. But then again, they pay me good money to do so 🙂

×