![]() |
|||||||||||||||||
|
|
|||||||||||||||||
|
|
|||||||||
|
Delphi |
DELPHI DEVELOPER SUPPORT
Areas of concentration under: rtl
Area: rtl\delphi Problem: Misuse of the FillChar procedure in the source within MConnect.pas Area: rtl\delphi Problem:
You should add all the compiler directive that
_must_ be set correctly at the top of each unit.
For instance, in SysUtils.Pas you have:
procedure Abort;
function ReturnAddr: Pointer;
asm
// MOV EAX,[ESP + 4] !!! codegen
dependant
MOV EAX,[EBP - 4]
end;
begin
raise EAbort.Create(SOperationAborted) at
ReturnAddr;
end;
The assembly code assumes that the unit was
compiled with a certain set of compiler options.
These options should be included at the top of the
unit, but currently you only have:
{$H+}
I know that at least TypInfo has the same problem
(it must be compiled with $Z1).
Area: rtl\delphi Problem: function FindCmdLineSwitch in System unit fails if SwitchChars param is empty. Steps:
Create an Application.
Add a button.
in OnCreate handler for the form add:
var
i: Integer;
begin
Button1.Visible := FindCmdLineSwitch('test', [],
TRUE);
for i := 1 to ParamCount do
if CompareText('test', ParamStr(i)) = 0 then
ShowMessage('Test in Command Line');
In Run,Parameters add 'test' as command line
parameter.
Run the application.
The button will NOT be visible, even though the
command-line switch is there (message box
appears).
The problem is in the FindCmdLineSwitch function.
It does a copy excluding the first char of the Switch
String passed in even if the SwitchChars set is
empty.
Area: rtl\delphi\date and time Problem: function Now calls GetLocalTime twice. But it should call GetLocalTime only once because date and time may change between two callings. Area: rtl\delphi\date and time Problem: Midas issue: Dates from 1/1/00-1/1/49 when inserted/modified should be stored as 1/1/2000-1/1/2049 according to the Y2K rules followed by BDE. It is currently being inserted as 1/1/1900-1/1/1949 Area: rtl\delphi\file management Problem: FileSize returns an integer and probably should be changed to return a cardinal. Area: rtl\delphi\file management Problem: The FileAge RTL routine will not return the date/time stamp of a directory - the implementation checks to ensure it is not looking at a directory. Area: rtl\delphi\file management Problem: Using FindFirst searching *only* for directory entries (faDirectory) does not work properly. It acts like faDirectory is the same as faAnyFile. Workaround: A work around is to search through all files and check each file to see if the faDirectory attribute exists for that file. Area: rtl\delphi\format and float Problem: Several floating-point values in the vicinity of 9.92E-265 are not formatted properly with the various float-to-string formatting routines. Area: rtl\delphi\other rtl Problem: In D4 a blank project now compiles to 250880 bytes. In D3 it was 179712 bytes. Area: rtl\delphi\other rtl Problem: From user web entry: New LENGTH support for dynamic arrays conflicts with PCHAR typecasting to strings. Returns size of array instead of length of PCHAR when used with static array. [Peter, I don't think there is anything that can be done about this, since dynamic arrays introduce a certain ambiguity in this situation - using Length on bounded arrays as well as dynamic arrays - but I thought you should see it - MD] Area: rtl\delphi\other rtl Problem: ofnProjectDesktopLoad notification does not supply a filename Steps: 1. Create and register an IOTAIDENotifier. 2. ofnProjectDesktopLoad notifiers supply an empty string as the file name, not the .DSK file. (ofnProjectDesktopSave does supply a filename.) Area: rtl\delphi\other rtl Problem: TIMenuItemIntf.SetCaption for right-most menu item does not update menu bar. Steps: 1. Create an expert that adds a menu item to the menu bar using TIMenuItemIntf. Add the new menu item after HelpMenu. 2. Change the new menu item's caption to make it longer. Delphi does not increase the size of the menu bar to accomodate the new menu item caption. Area: rtl\delphi\rtl exceptions Problem: With overflow checking enabled, exceeding the range of an Int64 does not raise an integer overflow exception as expected. Area: rtl\delphi\winapi Problem: In Windows.pas, we define almost every structure needed to dissect the PE file format EXCEPT _IMAGE_DOS_HEADER, which is the first step in getting into the image. Area: rtl\delphi\winapi Problem: TPoint parameters in event types are converted to 'tagPoint' when the IDE adds method handlers. That in itself is a curiosity, but the real problem is when you try and use existing code that has TPoint event parameters. Then the IDE says "The Component1Event method referenced by Component1.OnEvent has a incompatible parameter list. Remove the reference?" If you say 'no' to this, things build Ok, as expected. It asks the above question very often though. Steps: This is a contrived example to illustrate the problem. 1. Create a new project. 2. Add an event handler for the forms OnMouseWheelDown event. Note the 'tagPoint' parameter. 3. To simulate using existing code with TPoint parameters, change the tagPoint type to TPoint in the interface and implementation sections. 4. Now try and compile. You will get the IDE warning. Say no and everything will be ok - this time. Every compile, every save, etc. the IDE warning is raised. Area: rtl\delphi\winapi Problem: HttpOpenRequestA has incorrect parameters to pass an array of PChars for accepted types Area: rtl\delphi\winapi Problem: Windows.Pas has two constants with _wrong_ values, INPUT_KEYBOARD and INPUT_HARDWARE. Steps: Look in Windows.Pas for the definitions of Input_Mouse, Input_Keyboard and Input_Hardware (used with the new sendInput API). They are all zero The MSDN claims the values should be: const INPUT_MOUSE = 0; INPUT_KEYBOARD = 1; INPUT_HARDWARE = 2; Area: rtl\delphi\winapi Problem: The following functions in WINDOWS.PAS are wrong: SetWindowRgn GetWindowRgn Both functions return BOOL while in fact they ought to return "Integer" (at least that is what Win32.hlp claims). This problem seems negligeble with SetWindowRgn, as it returns a non-zero value- However GetWindowRegion has multiple return values Area: rtl\delphi\winapi Problem: define _IMAGE_EXPORT_DIRECTORY in Windows.pas. Area: rtl\delphi\winapi Problem: Wrapping for TranslateCharSetInfo is incorrect Steps: var lpSrc : DWORD in TranslateCharSetInfo wrapper causes below code not to compile. In some cases (refer to dwFlags documentation section) lpSrc may be passed to function as an integer rather than an address. TranslateCharSetInfo( GetACP,CharSetInfo,TCI_SRCCODEPAGE ); Area: rtl\delphi\winapi Problem: The AW_BLEND = $00040000; is incorrect it should be $00080000; Area: rtl\delphi\winapi Problem: ExtractIconEx in ShellAPI.pas incorrectly defines icon handle parameters as "var LongWord". The ExtractIconEx functions receives a pointer to an array of integers. The definition in ShellAPI.pas (both Delphi 3 and Delphi 4) incorrectly accepts only a single handle. Area: rtl\delphi\winapi Problem: This is rather a suggestion for more safety than a bug report, because I think the problem may not be in Delphi, but Deplhi causes it to surface. VCL unit SCKTCOMP.PAS, line 872: function TCustomWinSocket.SendStreamPiece: Boolean; var Buffer: array[0..4095] of Byte; The buffer size is hard-coded 4096 (not even a defined constant!) Data chunks of this size are being sent to Winsock. Default MTU in Win95 is, I believe, 576 bytes, and 4096-byte chunks cause Winsock buffer to overflow, freezing Win95 dead. I suggest changing 4096 bytes to 576 (which is the minimum MTU recommended by RFC). Area: rtl\delphi\winapi Problem: NT 4 SP3 & Windows 98 now support an API SendInput. Delphi 4 has a decration for this API and all its supported structures, but with a common typo. The MSDN says that each of the INPUT records has a field called dwExtraInfo. Delphi declares this as dwExtractInfo Steps: Look in Windows.Pas at the definitions of tagMouseInput, tagKeyBdInput and tagHardwareInput. The final DWORD fields are all called dwExtractInfo whereas the MSDN calls it dwExtraInfo
NOTE: These listings are for informational use only. It is not intended for use when calling Borland's Developer Support Department. If you have any suggestions or complaints about these 'Delphi Enhancements and Fixes' pages, please contact the Delphi Administrator. This e-mail address is not intended for support issues. |
|
|
|
|||||
| Made in Borland® Copyright© 1994-2003 Borland Software Corporation. All rights reserved. Report Piracy, Legal Notices, Privacy Policy Last Modified Thursday, 22-Mar-2001 18:57:03 EST |
|||||