Old spr bug occurs when changing from VFP8 to VFP9

This is an odd one that I doubt anyone has encountered but I'll throw it
out in case I get lucky:

We have a large application (hundreds of screens) that was developed in
the FP2.6 days that has been working fine under VFP8. For our next
release we'd thought it would be a good idea to move the development to
the latest version of VFP9 (SP1). We thought we got through the
transition clean but now a strange problem has popped up.

On quite a few of the old SPRs that were created with 2.6 where we have
a list that is populated from a field the list is not being refreshed
when the user selects to add a record (via a button). The code behind
the button just does:

APPEND BLANK
SHOW GETS

If you put your cursor in the list then it refreshes correctly and shows
you the new record.

What's odd is there is also a button that deletes a record. It has code
that deletes the record and then does a "SHOW GETS". This button works
fine.

If I run the code in VFP8 it works as intended. If I then run it with
VFP9 I get the quirky behavior.

Any insight would be greatly appreciated,

- Lee Blue

Dan
Thu Sep 06 09:14:52 PDT 2007

Looks like you've found a bug.

No surprise there. You're running code that was deprecated (and "quirky")
five versions ago.

Converted SPRs have always been a hybrid beast. They run in a special mode
where the variable scoping rules are different and you have "forms" that
aren't really forms and they have a setting for .WindowType that cannot be
created from scratch. The mean kids on the playground would say SPRs ride
the short bus.

If you can put together a simple demo that shows this behavior, I'd open a
support incident with PSS. But don't hold your breath. I'd bet strongly on
this getting marked as "won't fix".

Dan


Lee Blue wrote:
> This is an odd one that I doubt anyone has encountered but I'll throw
> it out in case I get lucky:
>
> We have a large application (hundreds of screens) that was developed
> in the FP2.6 days that has been working fine under VFP8. For our next
> release we'd thought it would be a good idea to move the development
> to the latest version of VFP9 (SP1). We thought we got through the
> transition clean but now a strange problem has popped up.
>
> On quite a few of the old SPRs that were created with 2.6 where we
> have a list that is populated from a field the list is not being
> refreshed when the user selects to add a record (via a button). The
> code behind the button just does:
>
> APPEND BLANK
> SHOW GETS
>
> If you put your cursor in the list then it refreshes correctly and
> shows you the new record.
>
> What's odd is there is also a button that deletes a record. It has
> code that deletes the record and then does a "SHOW GETS". This button
> works fine.
>
> If I run the code in VFP8 it works as intended. If I then run it with
> VFP9 I get the quirky behavior.
>
> Any insight would be greatly appreciated,
>
> - Lee Blue

Lee
Tue Sep 11 07:36:26 PDT 2007

In article <e8TpPEK8HHA.1164@TK2MSFTNGP02.phx.gbl>, spam@microsoft.com
says...
> Looks like you've found a bug.
>
> No surprise there. You're running code that was deprecated (and "quirky")
> five versions ago.
>
> Converted SPRs have always been a hybrid beast. They run in a special mode
> where the variable scoping rules are different and you have "forms" that
> aren't really forms and they have a setting for .WindowType that cannot be
> created from scratch. The mean kids on the playground would say SPRs ride
> the short bus.
>
> If you can put together a simple demo that shows this behavior, I'd open a
> support incident with PSS. But don't hold your breath. I'd bet strongly on
> this getting marked as "won't fix".
>
> Dan
>
>
> Lee Blue wrote:
> > This is an odd one that I doubt anyone has encountered but I'll throw
> > it out in case I get lucky:
> >
> > We have a large application (hundreds of screens) that was developed
> > in the FP2.6 days that has been working fine under VFP8. For our next
> > release we'd thought it would be a good idea to move the development
> > to the latest version of VFP9 (SP1). We thought we got through the
> > transition clean but now a strange problem has popped up.
Dan,

I grabbed the offending program and modified it to work outside the
application so you can see the problem. Can I attach it to one of these
post or is there another procedure?

I know the chances are slim that there is going to be a fix. I'd be
happy with a work around at this point. As stated before, the code on
the delete button does refresh the box. Is there a way to force the list
to refresh besides SHOW GETS or SHOW GET var?

- Lee

Dan
Tue Sep 11 11:17:01 PDT 2007

Lee Blue wrote:
> I grabbed the offending program and modified it to work outside the
> application so you can see the problem. Can I attach it to one of
> these post or is there another procedure?
>
> I know the chances are slim that there is going to be a fix. I'd be
> happy with a work around at this point. As stated before, the code on
> the delete button does refresh the box. Is there a way to force the
> list to refresh besides SHOW GETS or SHOW GET var?
>
> - Lee

As I said earlier, you should open a support incident with PSS. It's the
only way to get MS to pay any attention ... and the most likely way to find
a workaround.

Although the workaround is not to use @...GET in the first place. :-(

Dan

Thomas
Tue Sep 11 22:10:59 PDT 2007

Lee Blue schrieb:

> I grabbed the offending program and modified it to work outside the
> application so you can see the problem. Can I attach it to one of these
> post or is there another procedure?
>
> I know the chances are slim that there is going to be a fix. I'd be
> happy with a work around at this point. As stated before, the code on
> the delete button does refresh the box. Is there a way to force the list
> to refresh besides SHOW GETS or SHOW GET var?

There are some ways to get object handles even in SPR-based forms, and
you can call the current methods on these controls.
No idea if this could be a workaround...

HTH

thomas