trouble with form fired from menu

We've got an old 2.6 system that we run in VFP5. The screens are
maintained from a controls standpoint in 2.6. .SPR's are generated in
2.6 and then compiled and and run in VFP5.

Anyway, a foundation read is being utilized.

A menu system exists and everything functions quite well.

I've created some new functionality in a newly created form. I have
added a DO FORM command for the menu item. The form has it's WindowType
property set to Modal.

The problem is that I cannot access any controls on the form. I can
close the form using the "X" and the QueryUnload method is executed.

I have been away from Fox for awhile and I am sure it is something very
simple that I am missing.

Any ideas??

-- Patrick

man-wai
Sat Oct 08 00:17:44 CDT 2005

> The problem is that I cannot access any controls on the form. I can
> close the form using the "X" and the QueryUnload method is executed.

form.enabled?

--
.~. Might, Courage, Vision. http://www.linux-sxs.org
/ v \
/( _ )\ Linux 2.6.13
^ ^ 13:17:01 up 17 days 16:03 load average: 1.05 1.10 1.09

Fox&Sox
Sat Oct 08 06:08:52 CDT 2005

Yes, the form is enabled. I run this form "stand-alone" and everything
works perfectly. I is only when I plug it into the application that it
behaves in this fashion.

I even created a form with a single control (command button), plugged
it into the menu system and ran the app. I got the same behavior. The
app that this form is going to be a part of has been around for some
time. I am not 100% familiar with everything that is going on with it.
I can't see how the app could be affecting it in this way however,
since the app would not even know of the forms existence, since it is
not yet instantiated. It becomes instantiated when the user clicks the
menu item, by way of a DO FORM.

Really puzzling ...

(where is Columbo when you need him?)

;)

man-wai
Sun Oct 09 01:34:04 CDT 2005

Fox&Sox wrote:
> Yes, the form is enabled. I run this form "stand-alone" and everything
> works perfectly. I is only when I plug it into the application that it
> behaves in this fashion.

you aren't using formset, are you?

--
.~. Might, Courage, Vision. http://www.linux-sxs.org
/ v \
/( _ )\ Linux 2.6.13
^ ^ 14:33:01 up 18 days 17:19 load average: 1.00 1.01 1.00

Fox&Sox
Sun Oct 09 20:38:29 CDT 2005

no ... I have traced the code with debugger and I am not finding
anything that would be prohibiting the forms controls from being
"active". Tooltips are appearing for those controls that have them. And
as I said in intial message, the Windows Close button ("X") on the form
itself is working.

I have a feeling that it is going to be something really simple, once I
find it. These are the kind problems where the answer winds up being
"right in front of your face".

;)

Fred
Sun Oct 09 23:59:13 CDT 2005

If your fields on the form are using a table/cursor/view as the
ControlSource, it may be at EOF() or not contain any records.

--
Fred
Microsoft Visual FoxPro MVP


"Fox&Sox" <pblake61@gmail.com> wrote in message
news:1128908309.712775.223530@g43g2000cwa.googlegroups.com...
> no ... I have traced the code with debugger and I am not finding
> anything that would be prohibiting the forms controls from being
> "active". Tooltips are appearing for those controls that have them. And
> as I said in intial message, the Windows Close button ("X") on the form
> itself is working.
>
> I have a feeling that it is going to be something really simple, once I
> find it. These are the kind problems where the answer winds up being
> "right in front of your face".
>
> ;)
>

Fox&Sox
Mon Oct 10 08:43:42 CDT 2005

Thanks for the info Fred, but that is not the case.

However, as I said earlier, this is a 2.6 legacy app that is compiled
(.spr & .prg source) and run in VFP 5. This is just the way it is, with
no plans of change anytime soon.

Now, the old app (2.6) utilizes a FOUNDATION READ ... a menu system is
installed from which the VFP 5 form is instantiated. If I place the
code to call the form prior to the point where the FOUNDATION READ is,
it fires up fine and functions properly (with a READ EVENTS following
the DO FORM. Now, if I let the FOUNDATION READ kick-in and select the
menu item for DOing the FORM. I get the above describe behavior.

It has been awhile since I have been in position to concern myself with
FOUNDATION READS in old 2.0 - 2.6 code. So I think I am just missing
the boat on some simple formality.

man-wai
Mon Oct 10 08:52:45 CDT 2005

> It has been awhile since I have been in position to concern myself with
> FOUNDATION READS in old 2.0 - 2.6 code. So I think I am just missing
> the boat on some simple formality.

You problem really puzzled me. If could you post some codes directly
from the app, trimmed to contain only the problem...



--
.~. Might, Courage, Vision. http://www.linux-sxs.org
/ v \
/( _ )\ Linux 2.6.13
^ ^ 21:51:01 up 20 days 37 min load average: 1.01 1.05 1.04

Andrew
Mon Oct 10 09:51:49 CDT 2005

"Fox&Sox" <pblake61@gmail.com> wrote in message
news:1128951822.777180.193510@g43g2000cwa.googlegroups.com...
> Thanks for the info Fred, but that is not the case.
>
> However, as I said earlier, this is a 2.6 legacy app that is compiled
> (.spr & .prg source) and run in VFP 5. This is just the way it is, with
> no plans of change anytime soon.
>
> Now, the old app (2.6) utilizes a FOUNDATION READ ... a menu system is
> installed from which the VFP 5 form is instantiated. If I place the
> code to call the form prior to the point where the FOUNDATION READ is,
> it fires up fine and functions properly (with a READ EVENTS following
> the DO FORM. Now, if I let the FOUNDATION READ kick-in and select the
> menu item for DOing the FORM. I get the above describe behavior.
>
> It has been awhile since I have been in position to concern myself with
> FOUNDATION READS in old 2.0 - 2.6 code. So I think I am just missing
> the boat on some simple formality.

The other forms that were already there and work, are they by any chance,
NOT modal windows?

Kind of the other way around but setting a screen modal in 2.6 has the
effect of disabling the menu when the .spr is doing its READ.

--
Regards
Andrew Howell

Fox&Sox
Mon Oct 10 10:05:57 CDT 2005

ANDREW - feels like we're onto something here.

When the app is fired up, a menu system is load ... a browse window
(within a nonmodal window) comes up showing customers. Now, depending
upon what is selected from the menu system another browse window (again
within a nonmodal window) comes up. Now, if the user selects a menu
item that fires a screen, that screen comes up modal. Everything works
fine on those screens which are really only the .SPR code compiled in
VFP 5.

The 2.6 screens that come up ARE modal, and yes the menu system cannot
be accessed. It appears that the only screens that are nonmodal are
those that contain browse windows with basic customer information to be
used for choosing information to work with. We have a "zoom" function
that allows the currently selected item from a browse window to be seen
in screen format. These screens are modal.

MAN-WAI - it may take me awhile to "trim" things down to relevant
portions. Please be patient with me, as my office is closed today and I
actually have some plans later today.

yes, I am still slightly confused ...

I really am appreciating the feedback that I am getting from you guys.

Fox&Sox
Mon Oct 10 19:17:21 CDT 2005

FINALLY !!!

I have it figured out ... and yes, it was me not Foxpro.

What I had to do was eliminate the READ VALID (foundation read) and
replace it with a READ EVENTS. Then in the menu item for exiting the
system, replace the command there with the CLEAR EVENTS command. I do
have some minor lingering application generated error msg to contend
with still, but as far as the app & my new orm playing well together,
it seems everything is great.

Thanks for all your help. It took bits and pieces of the things you all
threw out here for me to find the answer.

-- Are usenet groups awesome or what, they're not just for porn anymore
... ;)