Anders Melander

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;

Yeah. There's lot's of bugs and stuff that doesn't work (especially in the bitmap editor) right now. I'm rewriting large parts of it to use DevExpress controls instead of standard VCL or custom controls so it's not that stable at the moment.

Wow. Just wow.

The window handle is probably getting recreated between BeginUpdate and EndUpdate. What Peter said 🙂

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).

My resource editor supports PNG compression of any size icons. No SVG support though. http://melander.dk/reseditor/

TActionList.OnUpdate (and OnExecute) is different in that these fire once for every action in the actionlist.

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.

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.

FindCmdLineSwitchEx: Just replace it with: FindCmdLineSwitch('Session', Mode, True) or simply remove the whole block. It's just for testing.

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;

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.

My experience too.

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.

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.

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

FWIW, the Drop Source Analyzer demo from The Drag and Drop Component Suite does pretty much the same as InsideClipboard. 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.

Try diagnosing the problem with the attached utility: Drag from the Drop Source pane and drop onto Outlook. You should be able to see what data Outlook asks for. If you compare the sequence when dropping on a 32-bit Outlook to that of a 64-bit, then maybe it becomes clear what's going on. DragDropTracer.zip

What data types (text, filenames, bitmap etc) are you dragging? Edit: Never mind. I see from the ticket that you're dragging files.

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.

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 🙂

Oh, I thought you meant the "else after end" style but I guess you're shooting at "else...if" in general. Well yes, I guess a more flexible case would be nice, but I can also imagine the horrors people would create with it.

Pattern matching? You'll have to explain that one.

I see. Thanks. No need for a war; We all know there's only "One True Style" - and it's the one we use ourselves 🙂

Just out of curiosity, as I use this style myself, why do you "hate" it?