Sinu,
I dont know if its been answered satisfactorily. There are too many
replies to wade through. I recall that along the way Windows standard
changed from 0 being a null pointer to -1. I had to change some of my
code in stringlist to work. I think my solution was to just multiply by
2
There was no change in the “Windows standard”. It’s a simple error in some
poorly implemented error handling code added to the VCL at some point
(subsequently fixed in combo boxes, but not listboxes – as of D2006).
You needn’t have waded through all the replies to find that the answer was
Jolyon,
As I mentioned I was reporting on things 7 years old, with failing
memory quite common to my age.
And I am not going to spend the time searching for it to prove you right
or wrong. Again, from memory, Intel was changing the design of the
memory manager which was going to mean that
Intel didn’t write the Delphi memory manager. And in any event, the list index
out of bounds error triggered by storing -1 in the item data of a list/combobox
item had NOTHING what-so-ever to do with the implementation of ANY memory
manager or any changes in any memory manager.
I don’t
Did the D2007 version have the XP manifest?.on the same machine (XP
onwards) a program using XPManifest does invoke the later version of common
controls in COMCTRL32.DLL, so it is possible thats where the difference comes
from.
Of course this is only plausible if one of them was using
Hi
In D2007 + you don't need to ship the manifest. Delphi automatically
builds it in for you (unless you untick that option).
Cheers
Rob
Robert Martin
On 16/02/2010 10:13 p.m., John Bird wrote:
Did the D2007
version have the XP manifest?.on the same machine (XP
Hi all,
I came across a strange bug(???) in latest versions of Delphi.
Have a look at the following code.
procedure TForm1.Button1Click(Sender: TObject);
var
i : integer;
begin
ComboBox1.Clear;
ComboBox1.Items.AddObject('All Locations', TObject(-1));
ComboBox1.Items.AddObject('Only
It works as expected (i.e. displays -1) in Win32 D2007 for me in an
otherwise empty VCL Forms application.
Are you sure you have reproduced this exact code in a clean app in
D2007?
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz]
On
There is no possible way that I can see that “ShowMessage()” could yield a
“List Index out of bounds” error.
I suspect you must have made a mistake in representing the code. This clearly
isn’t simply copied and pasted from a working test case as there is a
fundamental compilation issue
I can confirm that
ListBox1.Items.AddObject('foo', TObject(-1));
ShowMessage(IntToStr(Integer(ListBox1.Items.Objects[0])));
gives an error but
ListBox1.Items.AddObject('foo', TObject(0));
ShowMessage(IntToStr(Integer(ListBox1.Items.Objects[0])));
does not
I think casting -1 to an object
In Delphi 7:
{$EXTERNALSYM CB_ERR}
CB_ERR = -1;
...
function TCustomComboBoxStrings.GetObject(Index: Integer): TObject;
begin
Result := TObject(SendMessage(ComboBox.Handle, CB_GETITEMDATA, Index, 0));
if Longint(Result) = CB_ERR then
Error(SListIndexError, Index);
end;
Edward
Who cares where -1 points to? - if you don't *use* TObject(-1) *as* a TObject
then it's simply smoke and mirrors to get the compiler to allow you to store a
particular pattern of 32-bits in a storage slot that is typed in a particular
way.
But yes, this code causes an error in BDS 2006,
One way to get around this would be to add your own descendant of
TListBox and add an Objects property that works as you would expect
(ie. use that instead of items.objects). Here's a quick sample I
knocked together:
unit MyListBox;
interface
uses
SysUtils, Classes, Controls, StdCtrls,
I often use the Object property of listbox and TStringList items to store
pointers, or just numbers for array subscripts. I don't see any problem doing
that as it can save a lot of time. It is just an integer variable internally.
I seem to remember coming across the same problem once (D7)
The reason why -1 raises an error is because some of the called
Windows API functions will return -1 to indicate an index error.
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin:
... or a helper function that can be used on any TListBox without requiring
a modification introduced on a specific base class (easily adapted for other
control types, obviously)
uses
RTLConsts;
type
TListBoxHelper = class(TListBox);
TStringsHelper = class(TStrings);
function
The reason why -1 raises an error is because some of the called
Windows API functions will return -1 to indicate an index error.
Yep, but since the VCL provides insulation from the API it should be testing
index errors *before* using them in order to eliminate and report such
errors more
you should care greatly, because this is violating OOP principles
I care about code that works and gets a job of work done. OO Principles are
for the classroom.
Obviously the GetObject source cares somewhat about what -1 points to.
No, it doesn't. It simply gets confused because the
Pointers and TObject are unsigned integers (cardinals) not (integer) casting
to -1 is converting to the cardinal equvalent, which when pulled back is
making an out of bounds integer..
just a guess and it probably has something to do with the compiler
typecasting rules you have designated.
On
Why do people insist on speculating as to the cause of the problem when they
can just look at the VCL source and see the very simple and ordinary
explanation ?!?!
The problem is simply an incorrect and misleading error raised by the VCL
based on a naïve assumption. No violation of OO
On Tue, Feb 16, 2010 at 11:55 AM, Jolyon Smith jsm...@deltics.co.nz wrote:
function ListBoxGetObject(const aListBox: TListBox; const aIndex: Integer):
TObject;
begin
if (aIndex 0) or (aIndex = aListBox.Items.Count) then
TStringsHelper(aListBox.Items).Error(SListIndexError, aIndex);
I think the point I was trying to make is that it is that the method
(/array indexer or whatever) was expecting a TObject - passing anything
else could result in unexpected results. The fact that -1 doesn't work
is therefor not a bug (unless you can have 1 byte sized objects).
Alister
Nope. What is expected is a 32-bit value. It is only the VCL that
fabricates a TObject façade for that stored value, in an attempt to be
helpful. If you only want to store an integer or other 32-bit value then
casting to/from TObject() is perfectly valid since the value is merely
passed to and
On Tue, Feb 16, 2010 at 1:55 PM, Alister Christie
alis...@salespartner.co.nz wrote:
I think the point I was trying to make is that it is that the method
(/array indexer or whatever) was expecting a TObject - passing anything
else could result in unexpected results.
Only if you stipulate that
interesting
if Longint(Result) = LB_ERR then Error(SListIndexError, Index);
it would seem that the error is not in delphi at all. Well.. they are simply
raising the Windows error which say that -1 is the error result for a bad
index access from windows. if delphi were to ignore this error
True, but as Joylon correctly points out, you can (in the VCL)
actually cater for the difference in a real index out of bounds
error and a LongInt(TObject) typecase returning -1.
It's a bug and should be logged on QC, if it isn't there already.
On Tue, Feb 16, 2010 at 12:50 PM, Kyley Harris
Ah crap. Apologies for spelling your name wrong Jolyon!
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with
Yes thats true. they could rewrite the VCL code to cater for that issue.
Cant say I've ever actually encountered this problem before.
normally if I am binding anything in a list box, then I am binding a real
pointer to some other object that might contain an integer property.. I dont
think I've
On Tue, Feb 16, 2010 at 2:50 PM, Kyley Harris ky...@harrissoftware.com wrote:
interesting
if Longint(Result) = LB_ERR then Error(SListIndexError, Index);
it would seem that the error is not in delphi at all. Well.. they are simply
raising the Windows error which say that -1 is the error
Win API returns -1 to indicate an error. Any error. Not a specific
error. Certainly not specifically a list index error.
Unfortunately, the Win API return value is ALSO the Item data value. So
if you store -1 and get -1 back it could be an error or it could be the
valid result.
The VCL
That sounds reasonable.
your last comment interests me.. we have been getting eOutofmemory errors in
logging very frequently on a machine that always has 4GB free ram :D
I'll have to research that more.
On Tue, Feb 16, 2010 at 3:06 PM, Jolyon Smith jsm...@deltics.co.nz wrote:
Win API returns
On Tue, Feb 16, 2010 at 3:06 PM, Jolyon Smith jsm...@deltics.co.nz wrote:
Win API returns -1 to indicate “an error”. Any error. Not a specific
error. Certainly not specifically a list index error.
Pardon me for being pedantic, but while I agree with everything else
you said, I feel the need
Good luck with GetLastError(). There's nothing to indicate that
LB_GETITEMDATA processing will set a Windows LastError.
And empirically I would have to say that it doesn't:
// On an empty Listbox1 ..
r := SendMessage(Listbox1.Handle, LB_GETITEMDATA, 100, 0);
if GetLastError 0 then
i tested getlasterror also and it does not fail when an invalid index is
returned.
As i mentioned earlier.. index[99] will not fail.. you just get -1 :D
pre-testing the range is the only bypass. or.. just store your data in a
structure thats kinder to -1 :)
On Tue, Feb 16, 2010 at 3:57 PM,
On Tue, Feb 16, 2010 at 3:57 PM, Jolyon Smith jsm...@deltics.co.nz wrote:
Good luck with GetLastError(). There's nothing to indicate that
LB_GETITEMDATA processing will set a Windows LastError.
And empirically I would have to say that it doesn't:
Hmm... empirically I would have to say it
r := SendMessage(Listbox1.Handle, LB_GETITEMDATA, 100, 0);
if GetLastError 0 then
RaiseLastOSError;
if r = -1 then
ShowMessage('oops');
Will yield only the oops message, no OS error.
Tested this code too. I get a system error, invalid index.
How odd.
Cheers,
Karl
D2006, and *I* get 0, -1, -1... no error
-Original Message-
From: delphi-boun...@delphi.org.nz [mailto:delphi-
boun...@delphi.org.nz] On Behalf Of Karl Reynolds
Sent: Tuesday, 16 February 2010 4:16 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Is it a bug in
But since we're talking about behavior in the OS not the VCL or compiler,
more pertinent perhaps is the OS:
I'm running on a fully SP'd and updated Windows XP
Are you running Vista/Windows 7 by any chance
-Original Message-
From: delphi-boun...@delphi.org.nz [mailto:delphi-
I'll add my cents..
under Delphi 7, getlasterror returns error 1413 as Karl said.. under Delphi
2007 no errors whatsoever. whats clear is that Getlasterror is unlreliable
in this situation as Microsoft says, because microsoft online help says the
getlasterror value cannot be controlled depending
Its not Friday is it?
On Tue, Feb 16, 2010 at 4:43 PM, Kyley Harris ky...@harrissoftware.comwrote:
I'll add my cents..
under Delphi 7, getlasterror returns error 1413 as Karl said.. under Delphi
2007 no errors whatsoever. whats clear is that Getlasterror is unlreliable
in this situation as
On Tue, Feb 16, 2010 at 4:34 PM, Jolyon Smith jsm...@deltics.co.nz wrote:
D2006, and *I* get 0, -1, -1... no error
On Tue, Feb 16, 2010 at 4:36 PM, Jolyon Smith jsm...@deltics.co.nz wrote:
But since we're talking about behavior in the OS not the VCL or compiler,
more pertinent perhaps is the
On Tue, Feb 16, 2010 at 4:43 PM, Kyley Harris ky...@harrissoftware.com wrote:
I'll add my cents..
under Delphi 7, getlasterror returns error 1413 as Karl said.. under Delphi
2007 no errors whatsoever. whats clear is that Getlasterror is unlreliable
in this situation as Microsoft says, because
the fact that it behaves different under delphi 7 and Delphi 2007 on the
same machine implies that there is some strange mystery at work in the
compiled code that is not obvious. its not a direct problem of the
underlying windows API.
As to using the GetLastError..
There is issue I have with
On Tue, Feb 16, 2010 at 5:03 PM, Kyley Harris ky...@harrissoftware.com wrote:
the fact that it behaves different under delphi 7 and Delphi 2007 on the
same machine implies that there is some strange mystery at work in the
compiled code that is not obvious. its not a direct problem of the
Versions of comctrl32.dll ??
Edward Koryagin
--- On Tue, 16/2/10, Kyley Harris ky...@harrissoftware.com wrote:
From: Kyley Harris ky...@harrissoftware.com
Subject: Re: [DUG] Is it a bug in latest version of Delphi?
To: NZ Borland Developers Group - Delphi List delphi@delphi.org.nz
i have both versions of delphi on the same machine. ran both tests at the
same time. weird
On Tue, Feb 16, 2010 at 7:43 PM, Edward Koryagin ed_iv2...@yahoo.co.nzwrote:
Versions of comctrl32.dll ??
Edward Koryagin
--- On Tue, 16/2/10, Kyley Harris ky...@harrissoftware.com wrote:
From:
46 matches
Mail list logo
