Anyone who knows how to work around this? It happens every once in a while right after logging in over RDP to a VM with running Delphi XE2 (but similarly also in other Delphi versions like XE7):
---------------------------
Error
---------------------------
Access violation at address 74FD82A4 in module 'shell32.dll'. Write of address 00000014.
---------------------------
OK Details >>
---------------------------
With the below stacktrace including the sanctuary which always give me the creeps.
Next Monday-Wednesday (7th till 9th of November) will the the 20th edition of the famous Delphi related EKON conference and post-conference workshops at the Hotel Meliá Düsseldorf.
It will be a blast, not the least because it’s an anniversary.
There are still a few spots left, so drop me a note if you’ve not reserved yet as I can get you a discount code.
Below is the the speaker line up. It’s an awesome bunch of guys and there’s plenty coverage for English speaking attendees: English sessions are below the speaker list.
Only Delphi 6 and 7 used DDP files (still a nice concept: diagrams to help understanding your DFM files)
A long time ago, I wrote a stackoverflow answer and later a blog post on how to find and get rid of empty DDP files as both Delphi versions had the habit of creating them:
The blog post was when I helped moving an ancient Delphi project to a more modern Delphi version (due to some personal stuff going on I never finished it) and I never used such old Delphi stuff again.
This week that answer got quite a bunch of upvotes on the stakcoverflow answer which means people are still using Delphi 6 and 7 based code. Who’d ever thought that 15 year old versions would still be used today?
This Plain Text Offenders site lists email screenshots of organisations sending back plain-text passwords they kept on file (According to Robert Love, Idera/Embarcadero should be on the list as well).
It is one of the most horrible things that can be done for a password.
Business and IT do many horrible things, so I really hope someone will start a similar site about SSL Labs F-rated domains. The ones that are so broken that they degraded their https to virtually plain-text http quality.
put your resources in a text RC file that can be compiled through a resource compiler
add these to your Delphi project via the project manager, so it generated RcCompile elements which instructs the build process to run the resource compiler first:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
While upgrading a truckload of Delphi stuff for a client, I came across the IMPLICITBUILDING directive in a few .dpk files that Delphi XE2 sometimes inserts but XE8 doesn’t.
This appears to be a Delphi XE2 specific thing that in younger Delphi versions has been solved properly SolarWind‘s answer on Stack Overflow:
The compiler directives which appear between the $IFDEF IMPLICITBUILDING and $ENDIF are normally passed as parameters by the compiler when explicitly compiling a package. Because these options change based on the configuration (debug / release) and target platform (Win32, Win64, OSX32) it’s problematic to have them statically defined in the package project source. When defined in the project source they will always override the options passed by the compiler. The $IFDEF prevents these options from being used during explicit compilation.
That seems to be a workaround for the problem that compiling packages with the msbuild script ignored all dproj compiler options because they were read from the dpk file by the compiler.
Some more references (I’ve saved them in the WayBack machine as the forums auto-expire posts):
Check out $(BDS)\source\cpprtl\Source\misc\unmangle.c – it contains the source code for the unmangling mechanism used by TDUMP, the debugger and the linker. (C++Builder and Delphi use the same mangling scheme.)
…
This has been around as long as BCC itself. However the file was called um.c instead of unmangle.c in older versions
Nullable<T> = record
… property Value: T read FValue; default;
… end;
Using the default directive to “hoist” the operators of “T“. Currently the default directive only works for array properties by “hoisting” the ‘[]‘ operator. Marking a non-array property with default will make the containing type behave as that type.
This, coupled with some intrinsic compiler knowledge of the Nullable<T> type will make Nullable<T> work without any addition of keywords or other standard functions or procedures.
Using the “default” directive on a non-array property will work for any type, except for having the null-propagation semantics.
When considering language features, I try and not only make it work for the intended purpose, but also broaden reach of any supporting feature. In the above scenario, even user-defined operators on “T” will be properly hoisted and used.