Hallvard Vassbotn

May be caused by scope issues? Looks like the interface references var FTask1: IOmniTimedTask; FTask2: IOmniTimedTask; Are global variables and thus live longer than the internal window handles that Omni uses internally to post messages? Clear the interface references (and thus free the underlying objects), or do something else in the app close down to stop / wait for the threads before the app goes down? Sounds like programmer error.

Great, thanks! 🙂

Remy, the first byte is 225, not 255..:)

XE 6 has been pretty good to us. We want/need to upgrade the production version (we already have the licenses) to latest to get proper (?) HighDPI support, but are still reluctant due to performance and stability issues. From the roadmap, it seems they still have to fix HighDPI issues, probably won’t be fully fixed until they dog food it by using it in the IDE, as indicated in the roadmap.

Use the source and the debugger? For instance, set a breakpoint in your destructor and see if and from where (stack trace) it is triggered.

Incomplete code? Using pointers is fine(*), repeating code, especially inside a loop, is not. Move expressions like: PUInt64Array(@oString[0]) outside the loop, assign to local vars. Then you can probably just use inc on the pointer vars instead of using slower array notation. (*) as long as you understand them, use them correctly, efficiently and readably.

You can a acquire the exception object to prevent it from being automatically freed. http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_AcquireExceptionObject.html

Yes, you get access to many tweaks and debug options, including full stack trace of memory leaks. From 2007: http://hallvards.blogspot.com/2007/05/use-full-fastmm-consider-donating.html?m=1

Typically debug-enabled version of memory manager. On Phone now, so can’t check, but I think FastMM4 uses a different pattern (all $80, IIRC)

What is the status of the HighDPI support now? Is it solid enough to be used in production? I wish they would dog food this by using it in the IDE.

I don’t see any problem with that. Unless that function was not available in an earlier version of the Delphi RTL. Maybe it it should be IFDEFed

> However, if you need information (for example, perhaps you work on low-level code for profilers or debuggers, or have code for stack manipulation, inline assembly and naked functions, or similar) feel free to contact us. Inquiring minds want to know! 🙂

I agree. Uninitialized Result in a function should give a warning. Period.

That’s because functions with record (and other structured) return types are really implemented as hidden var-parameters. IMO, they should have been implemented as out-params, to get proper warnings. Alas, functions returning structured types preceded support for out-parameters (IIRC), and they never went back to fix this.

I think the requirement to explicitly state reintroduce is a good thing. It avoids the issue of forgetting to add the override directive - if you really intended to do so.