Anders Melander

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

https://joeduffyblog.com/2006/08/22/priorityinduced-starvation-why-sleep1-is-better-than-sleep0-and-the-windows-balance-set-manager/

I got that one just last week. AFAIR, it too had to do with a array[0..0] of stuff. I can't really remember much about it because I was in a rush and just worked around it

Supposedly each request is handled by a thread - Like in every other middleware. If your experience is that an exception in the request handling of the middle-tier blocks the whole server then there's either something seriously wrong with the middleware or the architecture of the middle-tier. The problem is probably that the main thread is somehow involved in the request handling. Not that it's related to your problem, but if you want middle-tier exceptions passed back to the client, as exceptions, you can look in the DataSnap source code to see how it's done.

Impressive dedication 🙂 See if you can locate the Embarcadero Licence Manager somewhere on your system: LicenseManager.exe If you can run that, then you should be able to delete any prior license that might be in conflict with the new one. If everything else fails then you can try to delete all the license info manually. I believe it's in C:\ProgramData\Embarcadero\.licenses Note that this contains the license data for all Embarcadero products on your system so be careful. See also: https://docwiki.embarcadero.com/Support/en/Moving_from_Delphi_or_C%2B%2BBuilder_Community_Edition_to_another_edition

Well, you said The Unit Scope Names setting helps abstract away implementation details which was what I have been trying to get an explanation of - but never mind. The example I gave with PByteArray is real; I have a core unit which declares TByteArray (of which PByteArray is a pointer to) as array[0..0] while SysUtils declares it as array[0..32767]. Since these two are ambiguous I have to scope my use of PByteArray when both units are used. No problem, SysUtils.PByteArray(some_pointer) doesn't obfuscate the code much. System.SysUtils.PByteArray(some_pointer) however is bit too verbose for my taste. FWIW, I just resolved it with a local type declaration: type PByteArray = System.SysUtils.PByteArray;

You still have to explicitly declare, in the uses clause, where PByteArray comes from - regardless of which form you use. And in the case of identifier ambiguity there is no difference in how it is resolved, regardless of fully qualified namespace or implicit namespace. So how does that explain your statement: If they move an identifier from one unit to another, you still have to update your uses clause and any explicit namespacing, since Delphi doesn't really have namespaces. They can hide a move from Foo.SysUtils to Bar.SysUtils but not from System.SysUtils to System.FooUtils. I guess what you were referring to was a move from SysUtils to System.SysUtils.

Huh? How do they do that? Can you give an example?

I'm not sure I agree on that. I've just been through a refactoring session where SysUtils was replaced with System.Sysutils which in turn made it necessary to resolve a series of type references as System.Sysutils.PByteArray instead of Sysutils.PByteArray due to a duplicate type declaration. That certainly didn't improve readability.

Supposedly compiles faster...?

You are looking at the function declaration. As Christian implied, for API functions that exist in both an Ansi and a Unicode version, you need to look at the import declaration: function FindFirstFile; external kernelbase name 'FindFirstFileW'; and the declaration of TWin32FindData: TWin32FindData = TWin32FindDataW; I'm guessing it has been declared this way since the very first Unicode version of Delphi - as it should be. It's the same in C. In fact, the declarations were probably generated automatically from the C headers. I'm guessing the official Microsoft FindFirstFile documentation also mentions it.