Anders Melander

23929_tdocktabset_sample_application.ZIP Last time I looked, and it's been a while, the docking manager used in the IDE was a different one from the one in the VCL. The behavior of the VCL docking manager is (was?) hardcoded into TControl in a way that made it impossible to fix from the outside. I would say it depends on the users. I was talking about typical non-technical end-users. Obviously highly technical users, such as developers, have no problems using docking.

I gave up on the VCLs docking a long time ago, after having spent a ridiculous amount of time trying to work around its numerous bugs. It's broken beyond repair and should be deprecated and replaced. I use DevExpress docking now and I think it works really well. That said, from watching our users, and even our in-house supporters, I can tell you that ordinary users don't understand how to use docking at all. It's really painful to watch them trying to get the dock layout they want. So I think it's best to try and limit the range of docking features available to the user. For example: No auto-hide panels, no docked maximize/minimize. Even floating dock panels might be too advanced or simply not usable (undocked forms obscure the windows below) or unnecessary (multi-monitors are being replaced by wide monitors).

Another option is to use DirectShow. I know that can also be made to load from a stream. Google "Delphi DirectShow"

The application is closed source but I have attached the relevant unit (and one dependency). There are a lot of unrelated dependencies in that unit, since it is a part of a large resource editor framework, so unfortunately it's not as readable as it could be. The unit implements a viewer for video and sound media resources. amResourceViewMedia.pas amResourceViewMedia.dfm VFW.pas

I have some code that I use in my resource editor to display video from a memory stream, so it's definitely possible. I just looked and it's about 500-600 lines of code and involves a custom I/O handler among other horrors. Here's a screenshot: And here's a video: Hmm. Never mind with the video. I can't figure out how to create a video this forum supports.

One thing you can do, to direct activity to the discussions, is to convert issues to discussion unless they actually pertain to an acknowledged bug or an accepted change/feature/enhancement. That way the issue list becomes a list of work items and the discussions everything else.

Yes; It's called a tarpit 🙂

There's the old TMediaPlayer but AFAIR it's a pain (but possible) to get to work with TStream. A better alternative would be to import the type library for the Windows Media Player ActiveX and use that. https://chapmanworld.com/windows-media-player-in-delphi/

Apparently the standard design-time property editors doesn't fully support Variant. https://stackoverflow.com/questions/29979950/how-to-correctly-set-a-variant-published-property I've looked at the code of the property editor but I can't make sense of it so I can't tell if it should work or not. I would have to debug Delphi in Delphi to figure it out and... Nope. Don't compare against a boolean value. Use boolean logic: if not VarSameValue(FCheckedValue, Value)then Same with the test in IsCheckedValueStored. Just set result directly: Result := not VarSameValue(FCheckedValue, True);

Huh? var Msg: TMsg; while (PeekMessage(Msg, 0, WM_SETCURSOR, WM_SETCURSOR, PM_REMOVE)) do begin if (Msg.message = WM_QUIT) then begin PostQuitMessage(Msg.wParam); exit; end; DispatchMessage(Msg); end;

Yes, sorry. I got the two mixed up. Fixed now.

No. Why would you think that it was? My own experience is that only having the necessary units in the interface section improves compile time and reduces memory usage during compile. It also helps with identifying and minimizing dependencies as I become conscious of them when a unit has to be moved to the interface section.

Exactly. Let the OS manage the RAM; It knows where it's needed the most. There are some cases where a RAM disk makes sense but output from a compiler ain't it. TLDR; but I wouldn't trust a RAM manufacturer to be unbiased in this matter.

More DOS legacy. RAM-drives hasn't had any justification since 16-bit processors.

It sounds like you should focus on fixing your build environment first 🙂 Well, there you have it. subst is a leftover from DOS and should be avoided. A file in a virtual (subst) location has (at least) two paths: The virtual path and the physical path. Depending on what windows API a virtual filename is passed though you can either get a result that is relative to the virtual location or to the physical location. I can't give you a concrete example but I've seen it happen many times. For example, I would guess that if you resolve a virtual filename to a PIDL and then convert that back to a path, then you will end up with the physical path.

Where do you think the EXIF orientation data comes from? It comes from the camera orientation sensor. The problem here is to handle the EXIF data in an existing image.

Definitely. I'm not denying that it's a problem. I'm just saying that the problem isn't that it doesn't rotate automatically (because that would also be a problem). The problem is that it doesn't give us any way of knowing that the image needs to be rotated be display. You should probably report it as a bug against FMX.

FWIW, TBitmap/TJPEGImage are low-level image containers. It's not their job to rotate or mirror the image because they don't know what you want to do with the image after load. So, if anything, the problem is that the classes don't surface the EXIF information so you can apply the transformation after load if you want to.

The API: https://bitbucket.org/anders_melander/better-translation-manager/src/master/Source/amDialog.Manager.API.pas The implementation: https://bitbucket.org/anders_melander/better-translation-manager/src/master/Source/amDialog.Manager.pas And here's the commit that introduced it: https://bitbucket.org/anders_melander/better-translation-manager/commits/c1341cb4eaaab433ee1680fcbd22e5dc570a5b97 It contains a few examples of changing some modal dialogs from traditional Create/Free to interfaces & DialogManager.CreateDialog. As usual, sorry about bitbucket 😕

Not directly; Delphi unfortunately doesn't support "wildcard" includes like that. The way I do it, for something like dialogs, is to associate each dialog with an interface and then separate the implementation of the dialog from the interface: unit Foo.Dialogs.Bar.API; type IFooDialogBar = interface ['{4279694B-C3D6-4B2A-A134-CEACDF6185AF}'] function Execute: boolean; end; unit Foo.Dialogs.Bar; interface uses Forms, Foo.Dialogs.Bar.API; type TFormFooBar = class(TForm, IFooDialogBar) // ...other stuff here... private // IFooDialogBar function Execute: boolean; end; implementation function TFormFooBar.Execute: boolean; begin Result := (ShowModal = mrOK); end; In order to create the dialog you could use a factory function like Peter suggested: function FooDialogBar: IFooDialogBar; begin Result := TFormFooBar.Create(nil); end; You will then have to manage the lifetime of the dialog somehow. Since you are accessing the dialog object via an interface you can't just free it once you are done with it. It will have to be done via reference counting. Unfortunately the default TComponent reference counting will not do it so it will have to be modified (overridden). I have a dialog manager that takes care of all this without the need to modify anything. It handles both modal and non-modal dialogs. I'm in the process of adding it to the translation manager project, so the code it will probably be public later tonight or tomorrow. The dialog manager is used like this: // Register the dialog API in the initialization section of the disloag unit initialization DialogManager.RegisterDialogClass(IFooDialogBar, TFormFooBar); end; ... // Create dialog var DialogBar := DialogManager.CreateDialog(IFooDialogBar) as IFooDialogBar; // Display dialog if (DialogBar.Execute) then begin ... end; // Lifetime is controlled via reference counting. // When interface goes out of scope, the dialog object is destroyed. ...

It's really hard to understand what you are doing from your description. Please show us the code of a minimal example instead (and please use the code tag). // Like this

Nice!

In TFormSplash.UpdateBannerImage: if (Scale = 255) then PixDst^ := PixSrc^ else if (Scale = 0) then PixDst^ := PixSrc^ or $00FFFFFF // *** Change this *** else begin RGB := PixSrc^ and $00FFFFFF; RGB := RGB xor $00FFFFFF; // *** Add this *** PixDst^ := (PixSrc^ and $FF000000) or (Div255((RGB shr 16) * Scale) shl 16) or (Div255((RGB shr 8 and $FF) * Scale) shl 8) or (Div255((RGB and $FF) * Scale)); PixDst^ := PixDst^ xor $00FFFFFF; // *** Add this *** end; This isn't the most elegant solution but since the original code was a bit of a hack (which is also why the solution isn't obvious at all) I guess it doesn't matter. Anyway, what it does is invert the color of the source pixel, blend it with the (black) text, and then invert the result again.

Very nice!

Keep digging