"Richard Stephens" <rick@almsysinc.com> wrote in message
news:4621a2af$1@newsgroups.borland.com...
> TIdFTP's OnWork was recently changed to make the AWorkCount
> parameter an Int64, rather than Integer.
That change was implemented a year ago. It is not a recent change.
It was announced back in May 2005:
OnWork Events changed to 64 bit
http://www.indyproject.org/Sockets/Blogs/ChangeLog/2006_05_25.aspx
> I do not know what else in the routine changed, but when I
> even reference this in TIdFTP's OnWork, the access violation
> occurs.
The only way I can see that simply having an event handler assigned
could cause an AV is if you have an old version of Indy installed
before the Int64 change was implemented. If you create a project
under the new version, then load the same project under the old
version, the DFM is still going to assign the now-incorrect event
handler to the event, and Indy will happily take it asnd try to use it
at runtime. The DFM streaming system does not validate method
signatures at all.
> procedure TForm1.Button1Click(Sender: TObject);
> var
> W_LS: TStringList;
> begin
> W_LS := TStringList.Create;
> With IdFTP1 do try
> Username := 'xxx'; {Masked out}
> Password := 'xxx'; {Masked out}
> Host := 'xxx'; {Masked out}
> Connect;
> Except
> end;
> IdFTP1.ChangeDir('/');
> IdFTP1.List(W_LS);
> ListBox1.Items.Assign(W_LS);
> end;
Why are you catching exceptions from Connect() and then ignoring them?
If Connect() raises and exception, then something went wrong with the
connect and you should not be using it at all. Also, you don't need
the TStringList at all:
procedure TForm1.Button1Click(Sender: TObject);
begin
With IdFTP1 do
begin
Username := 'xxx'; {Masked out}
Password := 'xxx'; {Masked out}
Host := 'xxx'; {Masked out}
Connect;
try
ChangeDir('/');
List(ListBox1.Items);
except
Disconnect;
raise;
end;
end;
end;
Gambit
