Anders Melander

Works for me; The GIFs load and display without problems. It's probably a problem in your code (have you remembered to reset the stream position before load?) but you don't have to pursue it for my sake. I was just curios.

Okay but do you remember what the exception was? - or if you have one of the GIFs I can try for myself. I'm just curious because AFAIK there no known bugs in the GIF reader (and I wrote the original TGIFImage code back in... 1997).

How so?

It's in the source:

https://docwiki.embarcadero.com/RADStudio/Athens/en/12_Athens_-_Release_3#Delphi_Debugger I guess I could try it out and see if it could be worked around but since there isn't anything for us in this release I have better things to do.

Wow. It's been while since they released a version with zero improvements that I had, or could find, a need for. It's basically bug fixes + a technology preview IDE that I can't use because it can't debug the VCL. Oh well.

I use the same finger for LMB and scrolling so it's pretty awkward to do both at the same time. Using the middle finger to scroll totally loses the required motor precision. My mouse do have two scroll-wheels, a regular one and one at the thumb position, but I've only ever used the thumb scroll in games.

"that's it" meaning "implicitly include the 347 other units it depends on".

QP is the only place. These fora are just read by regular mortals like you and me. But... ask yourself if you really want them to use their resources on this issue and if it's likely to be implemented.

The site seems to be down https://www.elevatesoft.com/ and Tim has no traffic (for years) on any of the sites I could find where he has an account. No obituary matches on his name/age/location though, so at least there's that. Timothy James Young, 55, New York, FWIW.

> Is this not implied if I use TImage ? TImage is just a control that displays the data of a TPicture (TImage contains a TPicure object), so forget about TImage itself. None of the image formats, except maybe bmp/TBitmap, are "implied" by design. It has just gotten so that using the Graphics unit implicitly pulls in support for a lot of different image formats. But it's not because someone sat down and had deep thoughts about what image formats to support by default and how to do it. It just happened to end up that way because, I guess, there's nobody left at Embarcadero who gives a damn about these things. Not that I think there has ever been anyone there that understood graphics or cared about imaging.

This works for me: uses Math; procedure TFormMain.ApplyWindowState(const Bounds: TRect; State: TWindowState); var Monitor: TMonitor; WorkareaRect: TRect; NewTop, NewLeft, NewWidth, NewHeight: integer; begin ASSERT(Position= poDesigned); // Find the monitor containing the top/left corner. // If the point is outside available monitors then the nearest monitor is used. Monitor := Screen.MonitorFromPoint(Bounds.TopLeft); WorkareaRect := Monitor.WorkareaRect; NewHeight := Min(Bounds.Bottom-Bounds.Top, WorkareaRect.Bottom-WorkareaRect.Top); NewWidth := Min(Bounds.Right-Bounds.Left, WorkareaRect.Right-WorkareaRect.Left); if (PtInRect(WorkareaRect, Bounds.TopLeft)) then begin NewTop := Bounds.Top; NewLeft := Bounds.Left; end else begin // Center on monitor if top/left is outside screen (e.g. if a monitor has been // removed) NewTop := WorkareaRect.Top + ((WorkareaRect.Bottom-WorkareaRect.Top) - NewHeight) div 2; NewLeft := WorkareaRect.Left + ((WorkareaRect.Right-WorkareaRect.Left) - NewWidth) div 2; end; SetBounds(NewLeft, NewTop, NewWidth, NewHeight); if (State in [wsNormal, wsMaximized]) then WindowState := State; end; ... procedure TFormMain.FormCreate(Sender: TObject); begin ApplyWindowState(Rect(100, 100, 400, 400), wsMaximized); end;

I should mention that instead of relying on WIC, which is a library external to Delphi and thus outside your control, it would be better if you explicitly included/declared the image formats you want supported. For example, include the pngimage unit for PNG support, the jpeg unit for JPEG support, etc. I would also unregister the TWICImage class (see UnregisterFileFormat) as support for all the formats it support might not be a good thing. All the formats will just confuse your users.

The image formats that are missing on your "older OS" are the ones supplied by WIC (via the TWICImage class). TImage, or more precise TPicture, relies on different TGraphic implementations for image format support. The image formats you get by default, whether you like them or not, are the ones registered in the Graphics unit. Image formats are registered with TPicture.RegisterFileFormat and can be unregistered with TPicture.UnregisterFileFormat. The list of registered image formats is internal (private in the Graphics unit) and Embarcadero, in their infinite wisdom, has not provided us with any means of accessing or enumerating the list so the only info you can get about registered image formats are filename masks. See the TGraphic and TPicture documentation for more info.

OP: Unambiguous question about the behavior of X A: Here's some code that does something similar but doesn't answer your question. OP: Okay but what about my question about the behavior of X A: Here's some data that also doesn't answer the question. OP: Thanks but... B: Have you tried <something else> instead? OP: *flips desk* 🙂 Apart from that, https://www.scientificamerican.com/article/time-s-passage-is-probably-an-illusion/ But seriously, ignore the help. It's obviously not up to date. The behavior of Now is never going to change to match the help because that would break a lot of code and nobody needs it to have 1 second resolution. Even in Delphi 1 (which implemented Now as Date (and Time via the DOS INT 21h, function 2Ch (which had 10 mS resolution))) the resolution was better than 1 second. I too would go for TStopWatch - even if you don't need the precision.

It's not like I never use the mouse when coding (Ctrl+Click) but I find it much more efficient to use the keyboard as much as possible instead of switching back and forth. Selection is probably one of the things I would very rarely use the mouse for. I guess I would do word selection using Ctrl+arrow to move, Ctrl+Shift+arrow to select. etc. Place the caret using normal arrow navigation. Shift+up/down for selection, etc. It's not really something I think about but the fact that I didn't know that mouse-scroll.selection didn't work tells me that it isn't something that I have tried or something that I need. Anyway, we each have our own usage patterns. There's no right or wrong.

I use the keyboard for code and the mouse for UI design - like they were meant to 🙂 Why would you use the mouse for code?

FWIW, my wife who speaks "human" tells me that my directness was indeed impolite. So sorry, I guess.

For me this is the single most useful of their controls in terms of UI design. It can be be hard to work with if you need an unusual layout but for the bread and butter dialog layout it is just perfect. With regard to skinning, I recommend chosing one of the vector based skins (this avoids most of the bloat). If the user must be able to customize the color scheme, then just give them 3 choices: Light, Dark, Custom (selects among the available color palettes). As an example, here's the UI to do this from BTM: As far as I remember that whole dialog is a layout control.

Here's the latest (not HighDPI related though): https://supportcenter.devexpress.com/ticket/details/t1277096/drawing-of-screentip-description-does-not-take-skin-palette-into-account TLDR; It ended up as "won't do" since they deem it a corner case (ScreenTip with formatted text and skins) and too expensive to fix. Even though I don't think it's that much of a corner case I can't really blame them much; Resources are limited. I don't mind the workarounds that much. I do mind the cases where I have to patch their code because that is really a pain to maintain. A search, in the project I have open right now, for "work.?around.+devexpress" gives me 29 hits. Most have no reference to a DevExpress issue (and some have probably never been reported) but here's the first 5 that does have a reference (only one of them is HighDPI related): https://supportcenter.devexpress.com/ticket/details/t1135725 Requires patching https://supportcenter.devexpress.com/ticket/details/t1130612 Requires patching. I believe this one has just been resolved in the latest release. https://supportcenter.devexpress.com/ticket/details/t1073008 https://supportcenter.devexpress.com/ticket/details/t1263794 https://supportcenter.devexpress.com/ticket/details/t1267760 HighDPI problem. All the same issue. Will supposedly be fixed at some point... https://supportcenter.devexpress.com/ticket/details/t1270641 https://supportcenter.devexpress.com/ticket/details/t1195057

Well, I wouldn't say you don't have to worry; They work pretty well but they are not without their own bugs. Our code is littered with work-arounds for DevExpress bugs, many of them High-DPI related. If you enable skinning then TMainMenu and TPopupMenu are drawn by DevExpress. They also have treeview and listview controls based on TTreeView and TListView so migration should be fairly easy. TToolbar will have to be replaced but that should be no great loss.

The exception type is context that only has meaning in the server and the client might not even have code that implement the exception type. Of course the client middleware code can perform mapping between the server exception type and a client exception type, based on the string name, an error code or something like that, but why should it? The client just needs to know that a request failed so a generic exception should be adequate. It entirely depends on how the client is calling the server and what the client code is doing. Getting an exception back from a server call might be preferred to having to make a call, check an error code, decide on what to do. I.e. traditional error handling vs. exception handling. The client isn't expected to handle the server problem but it needs to know that something went wrong. What went wrong is just context that can be used to decide flow or fix the problem after the fact. Yes, of course that's what they are doing. And they do it because exception handling is often preferred to checking status codes after each call. If you have ever written code against COM servers using the safecall calling convention you would know. Safecall converts the regular COM error codes into exceptions which means that you can treat a COM object like you would any other Delphi object. You don't call GetLastError after each and every call to the object; You expect errors to be raised as exceptions. Now extend this to DCOM. The COM server might reside on another system but your error handling stays exactly the same. Errors in the COM objects are still raised as exceptions in the client. Any call stack that the server might pass on to the client is just context for a bug report and not meant to be consumed by the client. And client-side. Exactly. I should have read the whole thread before responding 🙂

That's okay. I don't mind critique. I don't think I was being impolite; I was direct. I assumed that the OP was a hobby programmer (or not a professional) since: He needed to ask the question at all. He used 24 years old code copied verbatim from experts-exchange. Code that anyone with a bit of experience should be able to write on their own. He didn't provide any details about the exception such as where it occurred, call stack, etc. which to me shows that he might be able to read code but doesn't understand debugging. Hence the suggestion that he learns how to debug. Next step would be to explain how to debug.

Thanks. I didn't get that memo 🙂

What do you mean by "when invoked"? When you click on the buttons? The code looks okay to me (apart from the funky casing) so the problem is probably in your application code. It should be a fairly easy to determine the source of the problem if you run your application in the debugger. If you don't know how to do that then it's about time you learn.