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.
The with clause effectively opens the scope containing field identifiers of the specified record variable, so that the field identifiers may occur as variable identifiers. (Thereby providing an opportunity for the compiler to optimize the qualified statement.)
Screenshots of this 1975 book are below the fold.
The Delphi (actually even before that Turbo Pascal compiler) has no measurable difference between with and non-with code.
The debugger however, still does not support with, and there are other drawbacks of which one is below.
The below code example is just one of many. I show it because I recently bumped into doing some long overdue code porting to Delphi XE3.
Since I’ve been bitten by using with a couple of times before, it didn’t take me long to find the cause.
Example code where FIConData is of type NOTIFYICONDATAW that used to compile fine:
with FIconData do
begin
cbSize := SizeOf(FIconData);
Wnd := Self.Handle;
uID := $DEDB;
uFlags := NIF_MESSAGE or NIF_ICON or NIF_TIP;
hIcon := Application.Icon.Handle;
uCallbackMessage := WM_CAS400NTIcon;
StrCopy(szTip, PChar(Caption));
end;
First a warning: when you have found the process holding open a file, and you want to forcibly close the handle, read this post why you should not: Windows Confidential: Forcing Handles Closed.
In fact:
if you forcibly need to close a handle to salvage something, you should reboot shortly afterwards.
One thing that annoys me no end about Windows is the old “sharing violation” error. Often you can’t identify what’s holding it open. Usually it’s just an editor or explorer just pointing to a relevant directory but sometimes I’ve had to resort to rebooting my machine.
Any suggestions on how to find the culprit?
All of the below solutions require you to run with Administrative privileges.
On current Windows versions, if you run them without UAC elevation, they will miss a lot of processes. And still: under some secured environments you won’t see all processes anyway.
My preferred answer is not on the list:
Quit the application that holds the handle
All the tools that show you the handles will indicate which process holds the handle.
Often, you can just quit that process, do your job on the affected file, then relaunch that process.
When the process is Explorer, there is a neat little trick that works for Windows Vista and up:
For explorer, btw, hold ctrl-shift and right-click a blank area of the start menu, and you’ll get “Exit Explorer” – ps, not quite Jeff’s answer.. – Mark Sowul
Another answer I like is to use Handle, as it is both a command-line tool, and allows for wildcard searching: Read the rest of this entry »
The Wiert Corner - irregular stream of stuff 