QEMM can cause problems.

Description

It seems that QEMM can cause problems. The reported problem was that after stopping on a breakpoint, a 'step' (F8) to the next line of code, in a piece of program in which a Text file variable was used, Delphi caused a system reboot.
The problem went away after disabling QEMM. Details:
Delphi 2.0 C/s
Windows 95 with Windows Plus!
QEMM 8.0
On Track Driver in the Extended BIOS

TMaskEdit causes a keyboard lock on some machines and a big slowdown and blinking numlock on others.

Description

By Anita-Maria K. Parolla, Christian Wiedemann, Paul Shepherd, Rogério Jacques, Rune Moberg. Fix by Stefan Hoffmeister

Anita-Maria K. Parolla wrote:
In some computer/keyboard combinations (I isolated my problem to only those that have a ps2 bus, and not all of them) pressing a key (usually a number) causes to keyboard lock. I did not have this problem with regular TMaskEdit component but than I hardly ever used this component.

I have a large number of clients that use my software (all over America). I would say that about 6 of them reported the problem. At the beginning I thought it was a particularly bad joke and the people just do not know how to use a computer. But one of them realized I do not take him seriously and shipped me his entire box (NEW system: Hewlett Packard, Pentium 133 MHz, PS2 keyboard and PS2 mouse, Windows 3.11). Gosh, I got the shock of my life! Since then the problem is spreading because they buy brand name new computers (Compaq, Hewlett Packard, companies who switch from the old serial mouse to PS2 Mouse and keyboard).

BTW, I subscribe to ddj-thread listserv (from cobb tips etc) and I once uploaded a question about this problem. Apparently some other people have seen it, too, and they informed me it was a bug in Delphi. I talked also to Borland. They deny it is their problem, they said it happen because of an old faulty keyboard. Actually I understand them. I did not believe either until I saw it with my own eyes. And regarding "an old faulty keyboard" claim. Sorry! Six absolutely new computers - brand name new computers (!). But it does not happen on all computers with PS2 bus. I have a Gateway 120 MHz with PS2 bus. Worked perfect! I took my keyboard (which worked properly with my machine) and put it on the computer with the problem and VOILA suddenly my good keyboard is an "an old faulty keyboard".

Christian Wiedemann wrote (16 Apr 1997):
This happens in Delphi 1 under Windows 3.1 on my P133 (Ok under 95 or on my 486DX2/66). Build a new form with a TMaskedit on it. I define any mask at design time (phone number for example). At run time, while entering data in the field, the keyboard gets locked (the numlock led is then turned off) and cannot be recovered (even after leaving the application and windows with the mouse) until rebooting the PC. Sometimes I can get out of this situation by double clicking in the field (the numlock led is turned on again and the keyboard is unlocked). Another surprising thing: if I do unlock the numerics (numlock key pressed to switch the led off) before typing anything in the field, it's ok.
This happens also with the TStringGrid component, allowing editing the cells and specifying an edit mask at runtime in the OnGetEditMask event. At last, if I don't use a mask, everything is allright....

Paul Shepherd wrote (23 June 1998):
I have had the same problem using Delphi 3.02. (Although the lock isn't permanent - it just makes the edit box run very slowly.)

Rogério Jacques wrote (6 October 1998):
I found the bug described by Anita-Maria and Christian and it occurs in all versions of Delphi and the correction described by Stefan Hoffmeister works in all versions. Thanks to Stefan.
Regards,
Rogerio

Rune Moberg wrote (18 Jan 1999):
I have additional info about "TMaskEdit causes keyboard lock on some machines".
Turns out that on the Intel SE440BX motherboard (with earlier BIOSes) and other BX/EX based Intel motherboards there is a problem calling SetKeyboardState with a null array (which is what TCustomMaskEdit is doing). Stefan's workaround seems to work ok though.
Dell btw uses a modified SE440BX motherboard and can't use Intel's own BIOS upgrades (atleast not directly). Dell's own BIOS upgrades (as of this date) does not incorporate any fix.
The problem is that a call to SetKeyboardState takes approx 500ms when a null array is used as argument. The Win32 API help states that: "Because the SetKeyboardState function alters the input state of the calling thread and not the global input state of the system, an application cannot use SetKeyboardState to set the NUM LOCK, CAPS LOCK, or SCROLL LOCK indicator lights on the keyboard. " But this is false. Num Lock was indeed affected. (hence when loading a form with lots of masked edits, numlock started blinking on the user's computer for several seconds!)
NT is a different beast entirely and is not affected. SetKeyboardState works as documented (doesn't affect status indicators) on all machines tested.
In September (or so) there was quite an uproar on the Intel newsgroups, because several users were unable to use their keyboard with Win98 using the current BIOS upgrade at that time. I believe Intel addressed this issue and also straightened out the SetKeyboardState (perhaps inadvertently?) problem as well.

Solution / workaround

Stefan Hoffmeister came up with this:

The following is the proposed solution to the TMaskEdit problem you are listing for Delphi 1. It has been posted on the newsgroups by many people and I really cannot point to the original authors. As I have never seen the problem MYSELF I cannot say whether the solution actually fixes the problem - the posters do claim though that this is the case. Since publication of the fix (below), reports have been received that it does fix the problem (RPS)

Solution:
One fix could be to change the VCL source code in MASK.PAS according to the following example:

procedure TCustomMaskEdit.SetCursor(Pos: Integer);
var
...
begin
...
    SetSel(SelStop, SelStop);

    if SelStart <> SelStop then
    begin
      GetKeyboardState(KeyState);

{$IFDEF FixMaskEdit}
      NewKeyState := KeyState;
{$ELSE}
      for I := Low(NewKeyState) to High(NewKeyState) do
        NewKeyState[I] := 0;
{$ENDIF}
      NewKeyState [VK_SHIFT] := $81;
      NewKeyState [VK_LEFT] := $81;
      SetKeyboardState(NewKeyState);
...

David S. Becker (dsb@plaza.ds.adp.com) has another fix for the same problem:

      GetKeyboardState(KeyState);
{$IFDEF FixMaskEdit}
      NewKeyState := KeyState;
      NewKeyState[VK_CONTROL] := $00;  { Up }
      NewKeyState[VK_MENU] := $00;  { Up - ALT key }
      NewKeyState[VK_SHIFT] := $80;  { Down }
      NewKeyState[VK_LEFT] := $80;  { Down }
{$ELSE}
      for I := Low(NewKeyState) to High(NewKeyState) do
        NewKeyState[I] := 0;
      NewKeyState [VK_SHIFT] := $81;
      NewKeyState [VK_LEFT] := $81;
{$ENDIF}
      SetKeyboardState(NewKeyState);

Now, the fixes given above are only useful to people who are able to recompile MASK.PAS. However, many people can't do that and have asked how the could obtain a fixed MASK.DCU.
To meet those requests, here's a copy you can download: mask.dcu; accompanied by a text file with instructions: mask.txt.

Out of memory on NT 4.0 systems

Description

I have seen reports about problems with Delphi and Windows NT 4.0 in the comp.lang.pascal.delphi.misc newsgroups some weeks/months ago, but I never saved those.
Now I got a bug report which may be related to this. Does anyone know what's going on here? Please let me/us know!
By Toni Santa
I´m compiling/linking (build all) my project on a pentium 133 (intel on a pride motherboard) with nt4 (italian edition) and 64 mb ram, harddisk 2 gb NTFS, delphi C/S 2.01 english; I always receive the error out of memory (the hd has about 1.7 gb of free space, the swap file is about 60 mb, and delphi is the only application loaded, the computer is connected to a novell 4.11 file server using the latest 32 bit client from novell); the same project compiles fine on a win95 computer with 32 mb ram! I tried just to reinstall delphi32.
Do you know something about this problem?

Some problems (some solved) with video cards: Diamond Fire GL 1000 pro (AGP) and STB Velocity 4400

Description

Reported by Paul Gallagher

I have experienced video driver problems. With both D3 and D4, with 95 and 98, when using the Diamond Fire GL 1000 pro (AGP). Component pallet was scrambled, icons shifted or components used the wrong Icons. Problem was eventually solved by doing a "clean" install of Windows 98. I used the same board and drivers, apparently I had remnants of older drives still on the system. The problem did go away though after reinstalling.

I then installed a Diamond Stealth 2 card with no problems.

Finally, I installed an STB Velocity 4400. After installing this board and driver, Delphi, and EVERY program written in Delphi Locked up on execution. I confirmed this with several programs I wrote, and also with a program called JobBoss (job shop production control software) JobBoss is an Access application, but it has several Delphi modules. No other programs were affected. Running with video acceleration off DID NOT help. After about 4 rounds of install/uninstall my system finally crashed giving me the error "Can't load User.exe, Windows must be reloaded" upon windows startup. I reinstalled windows which fixed the windows crash. I reinstalled D4, but was unsuccessful, however, the programs such as JobBoss once again worked. Finally, I completley removed D4 and then reinstalled. D4 then ran properly.

It is hard to blame Delphi if the problems go away after reinstalling drivers. But why is it that only Delphi is affected?? I suspect that they are using some non-standard API video calls that are causing trouble in very specific instances.

Since loading the STB card I seem to be having problems with the IDE. The Object inspector does not always display in the correct place, and quite often does not reappear when closing a program in the IDE.

With both cards I am having an inordinate amount of Access violations. Far more than with D3. Sometimes they appear without provocation when trying to close a project and will not go away without CTRL+ALT+DLT. A specific instance is when installing a dialog component when the Component.pas file is open in the IDE. This will ALWAYS give a violation.

Arentjan Banck supplied the following extra information(7 Oct 98):
If you look at the newsgroups (borland.publick.delphi.ide) you will find that these problems are well known. Here two copies of interesting replies from Inprise:

========================================================
Tom,

Yes, this is one way to work around the Imagelist / video driver problem.
However, it is not a solution that we can use in VCL.
The problem is very definitely related to adding individual bitmaps to the imagelist control, and to use of video memory by the driver. Small image lists start out being stored in video memory. As the image list grows, it eventually gets too big to fit in video memory and has to be moved to system memory. That is the point at which the STB card will lock up the system (at certain color depths) and at which some other cards will corrupt the images in the imagelist.

Your workaround avoids this problem by storing the imagelist in one chunk, so when it gets loaded at runtime there is no growth issue.
The problem also appears to require the use of DIBs and device bitmaps in conjunction with the image list. I can reproduce the problem on this particular STB machine using TBitmaps (DIBs) and raw ImageList api calls (no TImageList), but not with simple DDBs created with CreateCompatibleBitmap or LoadBitmap. The next round of testing will be to construct a pure API call sequence to reproduce this problem, to get Delphi and VCL out of the accusation loop.
Microsoft tools generally don't use the Imagelist's IStream capabilities (as demonstrated when IE4 beta versions of the imagelist control changed the binary stream format, breaking all Delphi 3 apps), and I'm not aware of Microsoft tools making much use of Win32 DIBSections. If the video driver has problems with managing Win32 DIBSections, then that would go a long way toward explaining why Delphi and BCB have been hit hard by these video driver problems while MS stuff hasn't.
I'm still researching the cause and possible workarounds to this imagelist problem. So far, the workarounds have only made matters worse. :/

-Danny

========================================================
Hi Robert,

The image list problem does stem from problems with certain video drivers. We use an image list for the glyphs on the palette of the IDE and as Delphi is loaded this image list is increased in size. The problem arises when the size of the image list grows too large for video card memory and requires copying to main memory to complete the growth operation. At this point the video driver fails thus causing many of the problems that people have mentioned. One thing you can do is try to reduce the number of installed packages/components that you have and eventually, you will likely be able to load the IDE. While I realize this is far from ideal we are aware of the problem and are proactively investigating solutions. We are constantly evaluating the need for additional product updates and this item is certainly on that list.

-Steve
Delphi R&D
(Please respond to the newsgroup unless stated otherwise in this message. I do not respond to unsolicited private email.)

========================================================
Try

1. Get the latest driver (www.s3.com or your vendor) Or www.stb.com
2. Start Delphi with the -ns switch
3. Under the [display] section of the SYSTEM.INI file add the following line

       BusThrottle=1 (reboot afterwards)

4. reduce the hardware acceleration for the card.
5. play with color depth/resolution; 1024x768 in 16 bit color seems the worse.
6. Get the latest DirectX drivers. (probably not needed for Win98 systems)
7. one person has found that no desktop wallpaper or a wallpaper that is smaller in size worked for him.

Jeff Overcash

Vitaly Markitanov wrote:
>
> I have same problem with video card S3.
> When i run delphi, i just see only welcom message, and my computer hanguped.
> help pls

Solution / workaround

A workaround for the lockup of the PC while loading Delphi was provided by Graham Prouse on 22 Jan 99:
The only way to get Delphi 4 to load correctly, is to open a console window in full screen mode and allow Delphi 4 to load in the background. This bug occurs _every_ time I load Delphi 4.

Setting Printer.PrinterIndex to -1 on an NT 3.51 system causes error Win32 Error. Code: 124

Description

Reported by H. Spetsmann

The actual error I get is:

Win32 Fehler. Code 124
Die Ebene des Systemaufrufs ist falsch.

translated that becomes something like

Win32 Error. Code: 124
Level of system call is incorrect.

...when the program is running in a NT3.51 environment.
The same happens when starting a printer Setupdialog.
Can anybody help? Any workaround ???

Per-Eric Larsson commented to this (7 Oct 98):
I've gotten the same error message when loading dll's written in D4 under NT3.51!
Basically I don't think D4 is meant for NT 3.51 - I've recompiled the code in D3 and every ting has worked OK