So if accessibility for the blind is important for your software, it would probably be a good idea to download the free demo version of JAWS and test your software.  If it doesn’t work, try making the manifest optional.

One would think that the makers of JAWS would want software producers to test their products with JAWS.  But according to a salesperson for Freedom Scientific, there is no developer program for the tool.  JAWS is moderately expensive — about $900 — but this is not a barrier for us.  What we would really like is to have access to a defect reporting system for JAWS and early access to future versions of the software.

Update:  Darrell Shandrow, from the Blind Access Journal, comments on this post.

Share This | Email this page to a friend

In the installation log, I found:

Patch (C:\DOCUME~1\CMS~1.VER\LOCALS~1\Temp\Microsoft Visual Studio 2008 SP1 (Beta)\VS90sp1-KB945140-X86-ENU.msp;C:\DOCUME~1\CMS~1.VER\LOCALS~1\Temp\Microsoft Visual Studio 2008 SP1 (Beta)\VC90sp1-KB947888-x86-enu.msp) install failed on product (Microsoft Visual Studio 2008 Professional Edition - ENU). Msi Log: <Microsoft Visual Studio 2008 SP1 (Beta)_20080521_093532362-MSP0.txt>

Opening the linked file, I saw this:

DEBUG: Error 2746: Transform RTM.1 invalid for package C:\WINDOWS\Installer\5d5916dc.msi. Expected product {80C06CCD-7D07-3DB6-86CD-B57B3F0614D8}, found product {D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}.

DEBUG: Error 2746: Transform RTM.2 invalid for package C:\WINDOWS\Installer\5d5916dc.msi. Expected product {91C325A6-D5DE-3444-B598-97DF50EE0FAF}, found product {D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}.

DEBUG: Error 2746: Transform RTM.3 invalid for package C:\WINDOWS\Installer\5d5916dc.msi. Expected product {4298C783-524F-3C3E-9B11-36FA64604B2B}, found product {D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}.

DEBUG: Error 2746: Transform RTM.4 invalid for package C:\WINDOWS\Installer\5d5916dc.msi. Expected product {8F10429A-DFF5-3B55-9306-0ADEB337CFD3}, found product {D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}.

DEBUG: Error 2746: Transform RTM.5 invalid for package C:\WINDOWS\Installer\5d5916dc.msi. Expected product {23D0117E-F9A5-364E-A379-70EC2DE02B9F}, found product {D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}.

DEBUG: Error 2746: Transform RTM.6 invalid for package C:\WINDOWS\Installer\5d5916dc.msi. Expected product {F434F50E-7614-3EA8-9008-2FB866B697DA}, found product {D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}.

DEBUG: Error 2746: Transform RTM.7 invalid for package C:\WINDOWS\Installer\5d5916dc.msi. Expected product {BA0C9AAF-1327-3F06-B49C-349B4BE8F740}, found product {D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}.

A commenter on Scott Guthrie’s blog, however, gave me a clue which eventually allowed me to figure out a fix. The installer for the beta cannot deal with hotfixes which have been applied to Visual Studio. Before running the installer, you need to perform the following steps:

1. Control Panel, Add or Remove Programs
2. Check "Show Updates"
3. Scroll to Microsoft Visual Studio 2008
4. If there are any hotfixes under this entry, click the Remove button for each

Now the installer should work. The Service Pack installer will add the hotfixes back for you.

Share This | Email this page to a friend

In Delphi code, I log in as SYSDBA and open an existing database. I execute the SQL:

ALTER DATABASE ADD ADMIN OPTION

The following exception occurs:

ClassName: "EIBInterBaseError"
Error Message:
"unsuccessful metadata update
STORE RDB$USERS failed"

This ring a bell with me, so I asked him to confirm that the ODS (On-Disk Structure; essentially, the version number of the database file format) of his database indicated that it actually was an InterBase 2007 database. InterBase 2007 does not automatically upgrade older databases to the newest file format; you have to backup and restore the database to accomplish this.

He responded:

The database had been automatically upgraded from InterBase 7, and reported
via the TIBDatabaseInfo properties that the On Disk Structure (ODS) Version
was 11.2′.

I backed up and restored the database and the ODS Version was then reported
as 12.0.

With this version of the database, the exception did not occur.

This tells me that ALTER DATABASE ADD ADMIN OPTION does not work unless the ODS is the latest version available for the current server version. I wish the error message was better, but at least the problem is easy to fix.

Share This | Email this page to a friend

Yesterday, and InterBase user reported on the IB newsgroups that he had tried the following steps:

1. Alter a procedure to change the number of arguments it takes.
2. Alter a trigger which calls that procedure, so that the trigger source passes the new member of the procedure arguments.

Now, if the dependency checking had been working, step 1 would have been impossible, due to the reference to the procedure within the trigger body.  The correct way of doing this process is to first ALTER the trigger source so that it does not reference the procedure, then change the procedure, then change the trigger source to reference the new procedure signature.  But step 1 did work for this user, and when he tried to step 2, he then received the dependency error. The reason he received the error in step 2 is that InterBase was checking the dependencies of the old (compiled) version of the trigger before it compiled the new version.  That doesn’t seem right; if we’re replacing the source code of a trigger, why do we care if the old version is legitimate? So there seemed to be at least two bugs here.

If you find yourself in this situation, probably the easiest way to work around the problem is to ALTER the procedure back to its original form, and then update the trigger and procedure in the correct order.

Share This | Email this page to a friend

Although Erlang is designed to encourage/facilitate a massively parallel programming style, its error handling may be even more noteworthy. Like everything else in Erlang, its error handling is designed to be distributed, and for good reason:

Error handling in Erlang is very different from error handling in conventional programming languages. The key observation here is to note that the error-handling mechanisms were designed for building fault-tolerant systems, and not merely for protecting from program exceptions. You cannot build a fault-tolerant system if you only have one computer. The minimal configuration for a fault tolerant system has two computers. These must be configured so that both observe each other. If one of the computers crashes, then the other computer must take over whatever the first computer was doing.

This means that the model for error handling is based on the idea of two computers that observe each other.

Erlang is famous for its features which help programmers to produce stable systems in the real world. Its shared nothing architecture and ability to hot-swap code are well-known. But these features are available in other systems. The "links" feature, on the other hand, seems to be unique. When you create a process in Erlang, you can link it to another process; this link essentially means, "If that process crashes, I’d like to crash, also; and if I crash, that process should die, too." Here is Armstrong’s description:

Links in Erlang are provided to control error propagation paths for errors between processes. An Erlang process will die if it evaluates illegal code, so, for example, if a process tries to divide by zero it will die. The basic model of error handling is to assume that some other process in the system will observe the death of the process and take appropriate corrective actions. But which process in the system should do this? If there are several thousand processes in the system then how do we know which process to inform when an error occurs? The answer is the linked process. If some process A evaluates the primitive link(B) then it becomes linked to A . If A dies then B is informed. If B dies then A is informed.

Using links, we can create sets of processes that are linked together. If these are normal processes, they will die immediately if they are linked to a process that dies with an error. The idea here is to create sets of processes such that if any process in the set dies, then they will all die. This mechanism provides the invariant that either all the processes in the set are alive or none of them are. This is very useful for programming error-recovery strategies in complex situations. As far as I know, no other programming language has anything remotely like this.

In addition to simply killing the linked process, the link can also function as a kind of signal to a system process that a group of processes have died, so that appropriate action can be taken, such as restarting a process group.

Like Armstrong, I cannot think of another system that works quite this way. The closest analogy I can think of is a distributed transaction. But distributed transactions have quite a bit more overhead, because they’re all about providing serializable access to shared data, which Erlang just doesn’t allow.

Armstrong says that the idea of links was inspired by the ‘C wire’ in early telephone exchanges:

The C wire went back to the exchange and through all the electromechanical relays involved in setting up a call. If anything went wrong, or if either partner terminated the call, then the C wire was grounded. Grounding the C wire caused a knock-on effect in the exchange that freed all resources connected to the C line.

Armstrong says that the links feature encourages a worker/supervisor style of programming which is "not possible in a single threaded language."

Share This | Email this page to a friend

On an unrelated point, I enjoyed the Steve Yegge blog post that I referenced earlier. There’s a lot of good stuff referenced there, and not just for users of dynamic languages. He cites work on, for example, how to make virtual method calls (nearly) as fast as static method calls, it least in places where it counts. From a paper published in 1994.

Share This | Email this page to a friend

Share This | Email this page to a friend

[20A635EB]{coreide100.bpl} DocModul.AnyModuleModified (Line 3466, "DocModul.pas" + 10) + $41
[20A635E5]{coreide100.bpl} DocModul.AnyModuleModified (Line 3466, "DocModul.pas" + 10) + $3B
[00419D8B]{bds.exe} AppMain.TAppBuilder.FileSaveAllActionUpdate (Line 4067, "ui\AppMain.pas" + 1) + $0
[200401A7]{rtl100.bpl } Classes.TBasicAction.SetOnExecute (Line 11109, "common\Classes.pas" + 9) + $9
[201513B1]{vcl100.bpl } Forms..TScrollBox + $231
[2004009D]{rtl100.bpl } Classes.TBasicAction.Destroy (Line 11048, "common\Classes.pas" + 2) + $5
[2013D8C7]{vcl100.bpl } Controls.TControl.ScaleConstraints (Line 4033, "Controls.pas" + 12) + $7
[2015E854]{vcl100.bpl } Forms.DoPosition (Line 6778, "Forms.pas" + 44) + $2
[2015E86E]{vcl100.bpl } Forms.DoPosition (Line 6778, "Forms.pas" + 44) + $1C
[2015E8DC]{vcl100.bpl } Forms.DoAlign (Line 6795, "Forms.pas" + 0) + $4
[201631AA]{vcl100.bpl } Clipbrd.TClipboard.AssignPicture (Line 386, "Clipbrd.pas" + 7) + $14
[201632F9]{vcl100.bpl } Clipbrd.TClipboard.SetAsHandle (Line 430, "Clipbrd.pas" + 0) + $9
[20162637]{vcl100.bpl } Forms.TCustomFormHelper.WriteGlassFrameBottom (Line 8945, "Forms.pas" + 2) + $0
[2016291F]{vcl100.bpl } Forms.TApplicationHelper.GetEnumAllWindowsOnActivateHint (Line 9087, "Forms.pas" + 0) + $3
[0042297A]{bds.exe } bds.bds (Line 195, "" + 7) + $7

Note the line in bold. Because this is an OnUpdate event, it’s going to repeat forever. The user is trapped. There is no chance to save your work, or to exit the IDE normally. You have to end task. Sure, this is a secondary error; it’s almost certainly the consequence of the preceding access violation, rather than a defect in the OnUpdate event itself. But because that event is not robust enough to handle the consequences of the previous error, the user is trapped.

My conclusion is that OnUpdate event handlers are dangerous if they do not detect anything that could possibly go wrong with the references they use, and exit gracefully in that case.

Share This | Email this page to a friend

Share This | Email this page to a friend

When we enabled XP themes for our applications, I started noticing a flashing on the screen the first time you went to each tab in the page control. A little testing demonstrated that the gradient background of the tab was being rendered before the controls were created.

This turned out to be a fairly difficult problem to solve. When the user changes tabs, I need to figure out to which tab they are changing, and create the controls for that tab if they are not already created. In the TPageControl.OnChanging event, I don’t know to which tab the user is changing. Unfortunately, both the TPageControl.OnChange and the TTabSheet.OnShow event occur after the background of the tab has already been painted. I needed a way to render the controls, if necessary, in between these events, but after the tab to which the user is changing is already known.

After some rooting around in the VCL source code, I came up with the following solution.

type
  TChangeToPageEvent = procedure (Sender: TObject; const APageIndex: Integer) of object;
  TChangeToEventPageControl = class(TPageControl)
  private
    FOnChangeToPage: TChangeToPageEvent;
    procedure DoOnChangeToPage(const APageIndex: Integer);
  protected
    procedure Change; override;
  public
    property OnChangeToPage: TChangeToPageEvent read FOnChangeToPage write FOnChangeToPage;
  end;

{ TChangeToEventPageControl }

procedure TChangeToEventPageControl.Change;
begin
  DoOnChangeToPage(TabIndex);
  inherited;
end;

procedure TChangeToEventPageControl.DoOnChangeToPage(const APageIndex: Integer);
begin
  if Assigned(FOnChangeToPage) then begin
    FOnChangeToPage(Self, APageIndex);
  end;
end;

Since I also create the page control itself dynamically, I don’t even have to install this on the component palette to make it work. Handling the OnChangeToPage event allows me to create the controls when the page to which the user is changing is known, but before the tab itself renders.

Share This | Email this page to a friend