Board index » delphi » Weird problem with 'with' 'try'...'finally'

Weird problem with 'with' 'try'...'finally'

Hi

I have a component derived from TCustomComboBox that saves state info in
the registry.  I do something like this on destroy

    with TRegistry.Create do
    Try
      RootKey:=HKEY_CURRENT_USER;
      //  blah blah blah
    Finally
      CloseKey;
      Free;
    end;

When the component is freed, I get 'component has no parent window' error.  
I couldn't figure out what the problem was.  Finally I tried using a
variable instead.

    reg:=TRegistry.Create;
    with reg do
    Try
      reg.RootKey:=HKEY_CURRENT_USER;
      // blah blah blah
    Finally
      reg.CloseKey;
      reg.Free;
    end;

And it was fine.  Why?

-- luu

Please remove the underscore _ in my address when replying by email

 

Re:Weird problem with 'with' 'try'...'finally'


In article <6gv1qo$...@bgtnsc02.worldnet.att.net>,
  "Luu Tran" <luu_t...@geocities.com> wrote:

Quote

> Hi

> I have a component derived from TCustomComboBox that saves state info in
> the registry.  I do something like this on destroy

>     with TRegistry.Create do
>     Try
>       RootKey:=HKEY_CURRENT_USER;
>       //  blah blah blah
>     Finally
>       CloseKey;
>       Free;
>     end;

> When the component is freed, I get 'component has no parent window' error.
> I couldn't figure out what the problem was.  Finally I tried using a
> variable instead.

>     reg:=TRegistry.Create;
>     with reg do
>     Try
>       reg.RootKey:=HKEY_CURRENT_USER;
>       // blah blah blah
>     Finally
>       reg.CloseKey;
>       reg.Free;
>     end;

> And it was fine.  Why?

         What does the _actual_ code look like? I tend to suspect that
the logic is not the way you think it is, so that you're actually
freeing something else in the first version.
         (Like if there's another "with" inside this one that could
cause this sort of confusion).

David C. Ullrich

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re:Weird problem with 'with' 'try'...'finally'


Quote
Luu Tran <luu_t...@geocities.com> wrote:

: I have a component derived from TCustomComboBox that saves state info in
: the registry.  I do something like this on destroy

:     with TRegistry.Create do
:     Try
:       RootKey:=HKEY_CURRENT_USER;
:       //  blah blah blah
:     Finally
:       CloseKey;
:       Free;
:     end;

        you have to assign a TRegistry variable. what you've got
above is the same as saying "TRegistry.Create.RootKey:=HKEY_CURRENT_USER".
This doesn't make sense. TRegistry.Create returns a pointer to a
TRegistry variable.

:     reg:=TRegistry.Create;
:     with reg do
:     Try
:       reg.RootKey:=HKEY_CURRENT_USER;
:       // blah blah blah
:     Finally
:       reg.CloseKey;
:       reg.Free;
:     end;

: And it was fine.  Why?

: -- luu

--
                              Bed
                bedn...@yallara.cs.rmit.edu.au
            http://www.geocities.com/Hollywood/2430
2nd Year Comp Sci @ RMIT & Programmer @ AMC Enterprises Pty Ltd

Re:Weird problem with 'with' 'try'...'finally'


Andrew James Bednarz schrieb in Nachricht
<6hjsbi$rs...@goanna.cs.rmit.edu.au>...

Quote
>Luu Tran <luu_t...@geocities.com> wrote:

>: I have a component derived from TCustomComboBox that saves state
info in
>: the registry.  I do something like this on destroy

>:     with TRegistry.Create do
>:     Try
>:       RootKey:=HKEY_CURRENT_USER;
>:       //  blah blah blah
>:     Finally
>:       CloseKey;
>:       Free;
>:     end;

> you have to assign a TRegistry variable. what you've got
>above is the same as saying

"TRegistry.Create.RootKey:=HKEY_CURRENT_USER".

Quote
>This doesn't make sense. TRegistry.Create returns a pointer to a
>TRegistry variable.

So? That should work perfectly. I'm a bit startled as to why it
doesn't. It's contrary to what you'd expect from a with statement. The
TRegistry object returned by create is the current object of the with
statement. So theoretically, it should work. It should be completely
equivalent to the following:

Quote
>:     reg:=TRegistry.Create;
>:     with reg do
>:     Try
>:       reg.RootKey:=HKEY_CURRENT_USER;
>:       // blah blah blah
>:     Finally
>:       reg.CloseKey;
>:       reg.Free;
>:     end;

>: And it was fine.  Why?

Rudy Velthuis

Re:Weird problem with 'with' 'try'...'finally'


I've found that the With statement isn't all that reliable and I can't
really come up with an explanation either. It seems that sometimes its
using a variable from the TForm parent object (self) that has the same
name as the component or object I'm using in the With statement. It
doesn't do it all the time which I find strange.

I suppose I'd need to look at the compiled code to see where the
Compiler is going wrong but I don't have the time. Besides the With
statement makes tracing code more difficult and sometimes the code isn't
as clear so I don't use it anymore.

Mitch Wolberg,
RockWare, Inc.

Quote
Rudy Velthuis wrote:

> Andrew James Bednarz schrieb in Nachricht
> <6hjsbi$rs...@goanna.cs.rmit.edu.au>...
> >Luu Tran <luu_t...@geocities.com> wrote:

> >: I have a component derived from TCustomComboBox that saves state
> info in
> >: the registry.  I do something like this on destroy

> >:     with TRegistry.Create do
> >:     Try
> >:       RootKey:=HKEY_CURRENT_USER;
> >:       //  blah blah blah
> >:     Finally
> >:       CloseKey;
> >:       Free;
> >:     end;

> > you have to assign a TRegistry variable. what you've got
> >above is the same as saying
> "TRegistry.Create.RootKey:=HKEY_CURRENT_USER".
> >This doesn't make sense. TRegistry.Create returns a pointer to a
> >TRegistry variable.

> So? That should work perfectly. I'm a bit startled as to why it
> doesn't. It's contrary to what you'd expect from a with statement. The
> TRegistry object returned by create is the current object of the with
> statement. So theoretically, it should work. It should be completely
> equivalent to the following:

> >:     reg:=TRegistry.Create;
> >:     with reg do
> >:     Try
> >:       reg.RootKey:=HKEY_CURRENT_USER;
> >:       // blah blah blah
> >:     Finally
> >:       reg.CloseKey;
> >:       reg.Free;
> >:     end;

> >: And it was fine.  Why?

> Rudy Velthuis

Re:Weird problem with 'with' 'try'...'finally'


Quote
>         you have to assign a TRegistry variable. what you've got
> above is the same as saying "TRegistry.Create.RootKey:=HKEY_CURRENT_USER".
> This doesn't make sense. TRegistry.Create returns a pointer to a
> TRegistry variable.

Nope. This works for me. And I use it a lot. Each time I would
need the variable only once, I don't use a local variable at all.

No memory leaks or other disadvantages because of try/finally .

Regards, W.L.

Re:Weird problem with 'with' 'try'...'finally'


In article <353F4E1C.5198A...@dnvr.uswest.net>,
  Mitch Wolberg <rk...@dnvr.uswest.net> wrote:

Quote

> I've found that the With statement isn't all that reliable and I can't
> really come up with an explanation either. It seems that sometimes its
> using a variable from the TForm parent object (self) that has the same
> name as the component or object I'm using in the With statement. It
> doesn't do it all the time which I find strange.

> I suppose I'd need to look at the compiled code to see where the
> Compiler is going wrong but I don't have the time. Besides the With
> statement makes tracing code more difficult and sometimes the code isn't
> as clear so I don't use it anymore.

        You don't have to use it if you're not happy with it. But
in fact the with statement works just fine - if you have code where
with doesn't do what you expect it's because of errors in your
code (ie bits in your code that don't do what you think they do,
or scope problems).
        There are plenty of errors it's easy to make with with -
for example

with AnObject do AMethod;

where AMethod is not actually a method of AnObject. If the form
(or some other object "containing" this code) has a method named
AMethod then this will call the form's AMethod method.

        Or you can go wrong with nested with's, where both
objects have methods with the same name. Or...

        Or there _could_ be actual problems with with, but
I'm not convinced just because you say so, you have to give
an example (and because of the nature of the common easy
errors it has to be a _complete_ example - when we see a
snippet there's no way to tell whether the code surrounding
the snippet is the cause of some error as above.)

David C. Ullrich

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Other Threads