Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Return control from running app to browse window
Message
From
02/07/1999 17:06:33
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00236784
Message ID:
00237057
Views:
14
>
>David,
>
>Make a form, put a grid in it, use it instead of a browse. The form with grid will you complete control over everything, the browse gives some control over some things.

Jim,

Massa say I got to go boom,boom,boom when boom,boom enough. Why Jar,Jar got to have college degree to go boom,boom...didn't got to before? ;-)

Thanks,

But I am on a limited budget trying to shoehorn an ancient app into VFP to take advantage of it's improved shared environment features.

Yes, I know that if I was an OOP expert I could just whip out what I want in two seconds. I need a more expedient solution, if one is possible.

That said, let me tell you what I am actually trying to do and maybe you can guide me to a quick fix.

In the old foxpro, you could set up a browse window with two panes. In the left would be a column of key values and in the right would be a single record, displayed in edit mode (is this called 'row major' form?). Not only was this simple to set up with the various clauses of the browse command, it also had one other very nice feature...to wit...click on a different key value in the left column and presto, the right pane refreshes with the new record nicely justified to the top of the pane.

Under VFP, using the same BROWSE command, the right pane does not always automatically refresh each time I select a new record by selecting a different row in the key column. If the new record selected is the next following record (in the current index order), the right pane is not refreshed although scrolling down on the right pane does reveal that the first field of the new record has been selected. VFP behaves as if the new record is within some virtual window it thinks is currently visible to the user...and since it's already visible, there's no need to 'reregister' it at the top of the pane. I've tried some obvious work arounds that involve changing the height of the browse window, to no avail.

I have tried everything I know to try to get VFP to do the sensible thing, which is to refresh the right pane with the new record EVERY time I select a new one ... the way it used to work.

Now I know that the POTENTIAL power of VFP's OOP quite outstrips anything the old FP did, and if I was starting from scratch on a major project, you bet that I'd become facile with all of VFP's wonderful features. But as you can see, what I've got almost works and I could sure save a lot of time on this project if some expert like you could just give me a little tweak that would get me where I want to go.

To be honest, the reason I want to momentarily escape from the BROWSE and then pop back to it is to gain access to the grid that underlies it's implementation. BROWSE NAME booga NOWAIT gives me access to the underlying grid. I was hoping to experiment by playing around with some of the grid's properties or methods to perhaps acheive the desired result. But after having changed some properties I need to pop back into the BROWSE window. So you see, I've come half-way to OOP already. (Now I know your on the other side of the OOP learning curve, so you've forgotten that that last half-step is not a snap...but trust me, it's not)

Now, if you cannot tell me how to make the BROWSE window resync the right pane the way I want it to, could you at least tell me how to return control to the BROWSE window after having issued BROWSE NAME booga NOWAIT? (Fact: booga.SetFocus doesn't work)

TIA for any help you can give.
"The Iron Fish: The water is cold...but the fish don't mind"
...Jay Jenks, boyhood chum
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform