colors in browse window 1

[chajjjed]

I am a hobby foxpro programmer...I had made a small account software
in foxprow DOS and then used it in foxprow for windows.
I want to use this in VFP 9.0 now.But I am not getting browse window colors
in VFP as I was getting in Windows Foxprow.

when I googled I got a solution from your article with the following code.


CODE
BROWSE NAME oBrowse nowait
oBrowse.BackColor = 255


But this works fine in a simple 3-4 line programme like


use xyz
BROWSE NAME oBrowse
oBrowse.BackColor = 255

But in a bigger programme the browse windows does not appear
due to "nowait" and programme moves to next line..
If I want to view Browse window I have to give
"cancel" command so that I exit from the programme and browse window
with colors remain open..

can any one give solution to me ?

with regards

Narendra

 

[JRB-Bldr]

foxprow DOS

That, in itself is a contradiction.
FOXPROW - the "W" stands for Windows
But you go on to specify DOS

Regardless......

I want to use this in VFP 9.0 now
If I want to view Browse window...

Lets start here....

You should now quit trying to use BROWSE windows in VFP9.
Instead you use a GRID within a FORM.
And in that GRID's Columns, you can use its DynamicBackColor to control the colors of each individual record typically based on a "control" field

To get familiar with how Visual Foxpro works (as opposed to FPW or FPD) you might want to spend some time looking at the free online VFP tutorials at:

http://www.garfieldhudson.com/FreeVideos.aspx

Good Luck,
JRB-Bldr

 

[TamarGranor]

If you're trying to use FoxPro 2.x code in VFP 9 (which, I agree, isn't a particularly good idea), you probably need to turn themes off to get the appearance you're used to. Try issuing:

_SCREEN.Themes = .F.

before you do anything else.

Tamar

 

[chajjjed]

Thanq Jrbbldr..foxprow was a typing error..
and yaa..I am using grids..there its ok..
but if I want colors in browse window then
Is there any solution...

Thanq TamarGranor..I had given the command
_SCREEN.Themes = .F
in the starting line of the programme..but still I am not getting colors in Browse command

 

[Olaf Doschke]

If you don't have NOWAIT in the Browse, the next code line happens after the browse window is closed, so yes, you don't get it colored. You must have NOWAIT if you want to act on the BROWSE window.

But then the form vanishes. Why does the browse vanish, if you use NOWAIT? Well, oBrowse becomes a variable created by the NAME clause, not the Name property of the Browse window. It has to be kept alive - in scope - even after the method or prg ends. because when oBrowse is released the window closes. This is the same effect you have with any object reference, the object vanishes, if the last variable storing a reference to it is released. And if there is just one variable, which is released at the end of code running, that closes the BROWSE window.

So how do you get out of this dilemma? You need the simplest form handler of the world, a bare native collection you keep available public and store any form references in. It has a double effect:
1. It keeps the reference alive and a form does not vanish (including browses)
2. It automatically removes the reference, if the form closes itself. So you don't need any form handler code to remove a reference to release a form.
That is a very clever concept MS did on this collection class, as it allows you to easily keep form references in scope as long as you need them, but also get rid of them from inside of the form. Especially since you can't write code into the Release method or QueryUnload of any Browse Window to ask a form handler to release the form referene it keeps, there is no Brows class you may subclass. It's simply sweet the collection detects any form closing and reacts to it by removing any item of it referencing it. This is only happening for forms, though, not for any other object baseclass.

PUBLIC goForms
goForms = CREATEOBJECT("collection")

USE ?
BROWSE NAME oBrowse nowait
goForms.add(oBrowse)
oBrowse.BackColor = RGB(255,0,0)

The only thing you can do a bit better is not using a public variable for the forms collection, but rather make that a property of your global Application object goApp. an instance of an application class handling all globally application specific things. The only public variable acceptable to even public variable opponents (like me and any sane developer). Naming it goApp is an unwritten law, a known convention about many application frameworks. You may even avoid that single public variable by attaching this to _screen or _vfp or the OLE object Application via Addproperty(_vfp,"oApp") and _vfp.oApp = CreateObject("yourapplicationclass").

Learn more about scoping of variables and objects/classes in general, and you'd know when any object releases. Even if you don't program OOP, you can't avoid using objects, not only because some are nativle there always. Any DO FORM also created an object, any control on a form is an object, etc. So get used to objects and the term object reference. That avoids many such questions and surprise moments. A last clue on this: When doing things the wrong way within VFP itself as IDE, you're saved by the IDE running. It keeps things in scope, which would end their scope in an exeutable. The most famoous thing nobody gets the first time (including me) is having a main not having READ EVENTS. The end of executing anything, returning from the last level of the callstack, an EXE finishes, forms vanish, but the IDE is a last stack level always there to hold a few things alive. This scoping issue needs to be understood.

If you take it serious, you nevertheless don't use BROWSE at all as any output or edit window. You are in the world of Windows and its forms, everything you present to a user should be a form. BROWSE just becomes a tool for you as developer to get a quick glance at a workarea or DBF. I can understand you may have lots of legacy code you would need to rewrite, but that's the way it is. It's just a kludge to keep Browses going. it should only be that and you should migrate any BROWSE usage to creating a popup form. you may even find better UI solutions in integrating a grid into a pageframe or any other way of making it a part of the main form.

Bye, Olaf.

 

[JRB-Bldr]

I am using grids..there its ok..
but if I want colors in browse window

I said it above and Olaf said it again:
For Visual Foxpro -

don't use BROWSE at all as any output or edit window.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

HI Narendra, and welcome to the forum.

Just to amplify what the others have said.

Essentially, a grid looks like a browse, and has very similar functionality. The main difference is that you have a lot more control over the appearance and behaviour of a grid. You place it on a form, and it remains visible for as long as the form is active.

To get started with a grid, follow these steps:

1. Create a new form in the form designer.

2. Go to the Project Manager. Drag your table onto the form (the table is xyz in your example). If you haven't got a Project Manager set up, you can also drag the table (the DBF file) from Windows Explorer or My Computer.

3. For each of the grid's Column objects (Column1, Column2, etc), change either the ForeColor, BackColor or both, to show the colours that you want.

4. Save the form and run it.

There's a lot more to know about grids, but the above steps should get you started.

You should also read this article, which gives some more useful information: Understanding the Visual FoxPro grid control.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

You said you already use grids, so it shouldn't be a problem to add further grids to your form or even create a specific form just as browse replacement with a little extra sugar, eg navigational buttons, close button, side infos about the table, reccount, current position, etc.

Why is the BROWSE bad? It's a window itself, but you already need a little tricky referencing it to change it's appearance and more, all things you have under full control at design time already with a grid in a form you have to do with code at run time. And there's a problem, if you now both want to manipulate the BROWSE appearance and still have the BROWSE as modal window to be able to react to changes the user made on data after the browse closes. You now can't know when the BROWSE closes, that can happen anytime later.

To have control about the looks AND when the form closes, you instead define a form with a grid on it and call it and let its Init set the grid, if you don't already set colors etc at design time in the form designer. Then you may call that form modal or modeless depending on what you want and can better recycle other code logic in your legacy application.

Bye, Olaf.

 

[chajjjed]

Thanq Olaf..

Thanq JRB-Bldr..

And thanks a lot to Mike.

 

[Dan Freeman]

It's actually pretty easy to completely replace Browse with a form/grid.

Start with a new form, add a grid. Nothing in the DE, no code so far.

In the form's init:

With Thisform.Grid1 && assumes default naming
   .top = 0
   .left = 0
   .height = Thisform.Height
   .width = Thisform.Width
Endwith

Repeat that code in the form's RESIZE method. (Or, even better, put the code in a custom form method and call that method from both Init and Resize.)

Save it as MyBrowse.

Ever after, when you want to browse a table all you have to do is DO FORM MyBrowse. The grid will "browse" whatever table is open in the current workarea.

Easy peasy.

From there, you can launch other efforts. Save it as a class and you can subclass it to serve any browse needs you have, but it's fully controllable by you rather than having all the fickleness of Foxpro's native browse.

Not bad for six lines of code that you can inherit all over yourself.

 

[Olaf Doschke]

You now just have to care about the caption for the basic browse, but indeed there are other options of the browse command not so easily mapped.
All is possible though, because a browse is a grid:

USE ?
Browse Name oBrowse NOWAIT
? oBrowse.Class

So the NAME clause of BROWSE gives you a reference to a grid object on a form. A form you have no good control over, though. Rolling your own you gain more control.
Also, what I already said in thread184-1632570 is still valid: You can "emulate" 1:1 any browse clauses by inspecing their effect on the Grid the browse really is.

Besides you also find Dan's code idea there, too.

Bye, Olaf.

 

[Dan Freeman]

Yeah, when they implemented BROWSE NAME (VFP 6.0?) they basically told us that BROWSE is really, deep in its bowels, just a grid. But it's in a form-that-isn't-really-a-form just as browse always was.

I used browse heavily back when it was the only way. As soon as I saw the grid I stopped using it entirely.

 

[Olaf Doschke]

Yes, the form around the browse grid is not a VFP form, it's a bare C++ TForm class I think. oBrowse.Parent is not an object, if you try to access that.

That's also a reason roll your own form (do it yourself) is the only way you gain control about the form init, release and more, if you like to. It's easy to make a more special BROWSE experience, in the first degree you are able to start this form modal or nonmodal, so your flow of code is as usual. The more code you add to the form, the more possibilities you get.

You can do more, you may turn it to a borderless form, you may use WindowsAPI like SetParent and let the Form be a child form of your form. Well, if you go that far, you could also just create a grid control in your form, but "you gain more control" really means that, it's therefore worth it to adjust your BROWSE calls to a DO FORM MyBrowse.

Bye, Olaf.

 

[Dan Freeman]

Back in the day, we had....

Browse Window <name>
Browse In Window <name>
Browse Window <name> In Window <name>

These were distinctly different commands with distinctly different behaviors and a dozen or so of us spend countless hours explaining them to people who never really got it. Now we have Browse <name> which is something entirely different yet again.

It's because browse always lived outside of what you were meant to use but people used it anyway so they gave us some kludges to help control it.

Don't. Use. Browse.