I had been using a similar technique in Delphi since before I found out about the [WayBack] TRecall class and thought: I think my TTemporaryCursor is smarter, as it is based on interfaces.
My [WayBack] TTemporaryCursor (now [WayBack] at bitbucket) class only stores an integer, so it cannot derive from TRecall. Besides it is based on IInterface which got introduced in Delphi 6, but was present as IUnknown since Delphi 3 (see [WayBack] Interface It! A quick guide to the ins and outs of interfaces in Delphi. By Jimmy Tharpe).
This means that TRecall could have been based on IInterface, so I wonder why it was not.
Note I’m not the first to publish about such a class (Malcolm Grooves wrote [WayBack] TCursorSnapshot, SwissDelphiCenter has [WayBack] TMyCursor, Nick Hodges published about [WayBack] TAutoCursor), it’s just that it has been in my tool box for so long, and written memento classes that you will see 2 articles on it this week.
In the mean time (this works with Delphi 2009 and up), I also wrote a small class that does similar things for any [WayBack] anonymous method. More on that tomorrow.
Make sure your EXE can write in the directory of the EXE.
The first makes sure all units are compiled with FullDebugMode (Delphi does not always do that automagically).
The second makes sure your EXE can access the DLL that writes out your *MemoryManager_EventLog.txt file containing memory leaks and other issues FastMM4 detected.
The reason is that parts of the .RES file are no more leading in the process of getting them from your project options to the final binary (EXE/DLL/BPL/…) of your project.
Delphi XE3 for instance can have these resource structures in the .VRC file:
All in all, most if not all of the .RES files are being auto-generated for at least a couple of years now so there is less and less need to put it under version control.
The problem is that if for one reason or the other, your project .RES file becomes readonly, and you get errors like mentioned in Why does a projects res file need to ….
Hadn’t been doing SOAP in Delphi for a while, and needed to send some Delphi data structures over the write where both Client and Server were going to be Delphi.
Since there are so many speakers that are able to speak English, it is interesting for non-German attendees as too, especially the post-conference workshop from Nick Hodges.
I’ll be speaking too (more on that below) and will be there all 3 days (plus the evening before and morning after to aid people with their Delphi related questions).
Among the speakers, these will do their sessions in English:
Some 20 years after someone thought it was a nice idea to allow spaces in path names on Windows, it still is a bad idea to rely that just “works” for everything.
Android SDK
– http://developer.android.com/sdk/index.html
– Windows:
- http://dl.google.com/android/installer_r13-windows.exe
- http://dl.google.com/android/android-sdk_r13-windows.zip Do not install in a directory with spaces (not C:\Program Files, but C:\android-sdk)
And it does still apply: though not mentioned in the Android SDK/ADT documentation, most of the batch files in the Android SDK ADT bundle are not compatible being stored in a path that has spaces.
Unquoted referrals to paths like this are used in most SDK batch files:
cd /d %~dp0
The only way to run these batch files is with the current directory being the directory of the batch file itself, or referring to them in their fully quoted form.
Another correct way would be to use short names, but that’s only done in find_java.bat:
%~dps0
Summary of the batch files and how they are affected:
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
Everyone knows there is a size difference between a gigabyte of memory, and a gigabyte of disk space.
The former is 102410241024, the latter is 100010001000.
To facilitate this, I’ve created a C# class UnitPrefixes containing quite a few constants and readonly values.
The class is below, but a few interesting facts first:
Most values are const, but a few are readonly static variables because they cannot calculated at compile time (the C# compiler by design does very limited calculations at compile time; it is complex enough as it already is).
As Jon Skeet explains, there are some other differences between const and readonly static, which is why I favour const.
Though all consts are positive, I could have used UInt32 and UInt64, but the .NET framework favours signed Int32 and Int64 types for parameters, so to avoid casting, I used the signed ones.
There is no Int128 or UInt128, but there is System.Numerics.BigInteger which I use for values too large for 64-bit integers.
Note that BigInteger is relatively new, so this code will only work in C# 4 or higher, and requires .NET 4 or higher.
This is also the place where I use the public readonly static fields, as I need to call the BigInteger constructor to initialize it.
I quickly found an import file had grown over the 2 gigabyte, so this was indeed the case.
The original developers didn’t do the file access using the 64-bit Seek/Position of the TStream descendant TFileStream.
Too bad, as now someone has to dig through the mothballs to find the sources (if they survived 3 different version control system switches), create a working development environment, and fix the bug.