delphi-2010

What's the reason this won't compile? type IInterfaceA = interface ['{44F93616-0161-4912-9D63-3E8AA140CA0D}'] procedure DoA; end; IInterfaceB = interface(IInterfaceA) ['{80CB6D35-E12F-462A-AAA9-E7C0F6FE0982}'] procedure DoB; end; TImplementsAB = class(TSingletonImplementation, IInterfaceB) procedure DoA; procedure DoB; end; var ImplementsAB: TImplementsAB; InterfaceA: IInterfaceA; InterfaceB: IInterfaceB; begin ImplementsAB := TImplementsAB.Create; InterfaceA := ImplementsAB; >> incompatible types ... end In contrast this is how I make it work: InterfaceA := ImplementsAB as InterfaceB; or

I have an app with a number of worker threads, one for each core. On a modern 8 core machine, I have 8 of these threads. My app loads a lot of plugins, which also have their own worker threads. Because the app uses huge blocks of memory (photos, eg. 200 MB) I have memory fragmentation problem. The problem is that every thread allocates the {$MAXSTACKSIZE ...} of address space. It's not using the physical memory but the adress space. I reduced the MAXSTACKSIZE from 1MB to 128KB and it seems to work, but I don't now if I'm near to the limit. Is there any possibility to measure how much stack is

When any TGraphic descendant registering its own graphic file format with a class procedure TPicture.RegisterFileFormat(), they're all stored in Graphics.FileFormats global variable. Too bad that FileFormats variable is not in the "interface" section of "Graphics.pas", so I can't access it. I need to read this variable to implement a special filter for my file-list control. Can I get that list without manual fixing the Graphics.pas's source code? Remy Lebeau You are working with a file-list control, and presumably thus a list of filenames. If you don't need to know the actual TGraphic class

I've got a custom frame I need to inherit from in multiple projects. This frame includes some code and some components, and it resides somewhere on disk, in it's own project directory. I don't want to COPY it to the Object Repository folder, that doesn't seem right to me: I'd end up having two copies of the form, one in my Mercurial-backed repository, one in Delphi's Object Repository. Absolutely not a good idea. What I want is to have my frame in a Package and have the Package do all that's required to make the frame known to the IDE and allow the IDE to create new siblings of the given frame

I have an app, which has multiple forms. All these forms have a PopupMenu. I build the menu items programatically, all under a common root menu item. I want ALL the menu items to call the same procedure, and the menu item itself is basically acting as an argument.... I had this working when I just had one form doing this functionality. I now have multiple forms needing to do this. I am moving all my code to a common unit. Example. Form A has PopupMenu 1. When clicked, call code in Unit CommonUnit. Form B has PopupMenu 2. When clicked, call code in unit CommonUnit. When I need to call my popup

TThread's resume method is deprecated in D2010. So, I thought it should now work like this: TMyThread = class (TThread) protected Execute; override; public constructor Create; end; ... TMyThread.Create; begin inherited Create (True); ... Start; end; Unfortunately I get an exception "Cannot call start on a running or supsended thread"...which seems weird to me considering the fact that the documentation tells me that I should call Start on a thread created in suspended mode. What am I missing here? Jeroen Wiert Pluimers The reason is that a Thread is not supposed to start itself . The thread

I am using the following code to copy text to the clipboard: Clipboard.Open; try Clipboard.AsText := GenerateClipboardText; finally Clipboard.Close; end; Seemingly at random I get "Cannot open clipboard: Access Denied" errors. I'm guessing that these errors are caused by other application locking the clipboard, but I never seem to be doing anything with other applications that should cause the locks. Strangely my users seem to be reporting more of the errors with Vista and Windows 7 than with XP. Is there a way to check if the clipboard is locked before trying to access it? This is not a

I asked a similar question about implicit interface variables not so long ago. The source of this question was a bug in my code due to me not being aware of the existence of an implicit interface variable created by the compiler. This variable was finalized when the procedure that owned it finished. This in turn caused a bug due to the lifetime of the variable being longer than I had anticipated. Now, I have a simple project to illustrate some interesting behaviour from the compiler: program ImplicitInterfaceLocals; {$APPTYPE CONSOLE} uses Classes; function Create: IInterface; begin Result :=