BROWSE PREFERENCE issue

[dmusicant]

My programs often issue Browse Preference <mypreference> clauses so I can customize my view of data. This is nice in that sometimes I want to see things one way, sometimes another. However, I have encountered problems using this technique. Case in point: I just modified the structure to a large table that has many fields, 29 fields in all. When my program does the usual BROWSE PREFERENCE <whatever> the newly added field in the table is not visible in that browse window. How can I deal with this problem? I want to see that field, move it to where I want it to appear, resize the width of the column, just like the other fields.

I figure there are probably a few ways of dealing with this. One would be to delete the foxuser.dbf table entirely, but this seems like gross overkill, since I'd lose all my preferences!

What do you suggest? Thank you for ideas!

Edit: Whoops, I didn't just have a browse preference in effect I also had a browse fields <field list> in effect, and that is the reason I couldn't see my newly added field!

 

[Mike Lewis]

Well, you could issue a BROWSE PREFERENCE with a different name. That will save the configuration in new Foxuser record. You can then restore it by issuing the command again with that same name.

Or, rather than deleting FOXUSER.*, it would be better to SET RESOURCE OFF, then do the new Browse, then SET RESOURCE ON again. (This technique is in fact explained in the Help file.)

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

Yeah, OK, these will work, I guess. Only problem is I have to figure out what the preference name is of the particular browse window that's open. That's opaque while I run the application, I have to dig down into the code to determine the preference name of the particular browse that's malfunctioning. Yes, I can do that.

Will issuing BROWSE PREFERENCE <mypreference> with SET RESOURCE OFF in effect bring up the browse with no settings and allow my to make changes, issue Control+W and have the new settings actually saved to the FOXUSER.DBF although SET('RESOURCE') is OFF?

 

[dmusicant]

Well, I just tried some things and this is confusing me. I set resource off in the command window and ran my application, going to one of my common browses. The typical column widths were not there. I pulled the columns closer together and expected to find my new field but it was still absent! Hmm.

Edit: Whoops! I just inspected my code and saw that I had a BROWSE FIELDS <field1, field2, etc.> command in the works. I added my field to the list and now it's there. As usual, it comes up at the extreme right side of the browse window when a preference is in effect and I have to move it to where I want it the first time I run the browse with the new field, but that's a minor annoyance compared to not seeing it at all!

 

[Mike Lewis]

It sounds like you're on the right track, Dan. But let me add one more option to the mix (and if I don't, I'm sure someone else will). Have you considered doing without the Browse altogether, and using a custom form containing a generic grid? If you take a look at thread184-1759534, you will see that Andrew is doing something similar.

The point is that a custom form would allow you to build in the necessary logic to deal with changes to the table structure, as well as giving you the ability to save or discard specific changes to the column order, column widths, etc. It would involve a bit of work to set it up, but it might well be a very useful tool for you.

Just a thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

Thanks Mike. I've had the idea that a grid might be the way to go for my two main apps, which use BROWSE exclusively. Those apps were written in FPW but I use VFP 9.0 to run them, so it would be worthwhile to ditch FPW for VFP 9.0 for some of the functionality. I could maybe retain the FPW screens, or some of them, so far all but the top level screen for one app have performed OK for me. There's some code behind those FPW screens, moving them to VFP forms would take some work.

I've worked with VFP applications, did programming and database administration extensively and for a period of over 2 years on a complex and advanced VFP app, took a couple of courses in VFP. However, I've never created my own grid (and it's been about 14 years since I had that job!) so I guess there would be a learning curve there.

My quibbles with my apps are that:

1. The browses always open with a certain font size, and at least some of the time I like it a fair bit larger. Occasionally I increase the font size in those browses.
2. The memo fields of the browses (i.e. I open a memo field seen in a browse) of one of my apps typically open with the font size maybe 9 point, and I usually want it enlarged to 14 point. I do that in the menus, and once saved, next time I open that memo field it usually opens in 14 point type, fine. But I would like to set things up (in many, most or maybe all) cases so that that memo field always opens with the font set at 14 point. Maybe I can arrange that using BROWSE, don't know, but I assume that I can do it using a grid arrangement.

Thanks for the help.

Dan

PS I haven't gotten around to getting VFP and my apps set up on my new tablet/laptop. It seems possible to me that I will be motivated to make some changes once I do that. I figure there's a fair chance that my apps won't run OK on the device and I'll be thinking about some changes.

PPS FYI, none of my tables are presently in a DBC. I suppose I could create DBC(s) for my tables and might benefit from doing so. My tables, in one of my apps, do belong to sets, and those sets are controlled by other free tables of (exclusively) metadata in tandem with code.

 

[Mike Lewis]

Dan, when I first read your question, I assumed that you were using browse as a developer tool - to check to see what's in a given table, either for debugging purposes or to check the results of a test run. But your most recent post suggests you are using them within your application - for the use of your end-users.

There's nothing wrong with that, but it's not something most developers would do. Grids are a much better choice. A grid gives you far more control than a browse, and it fits in well with the other controls on your forms. It's true that you will have a learning curve, but it's not all that difficult.

On another point, as you move from FPW to VFP, I would advise you not to retain your old FoxPro screens, and to go straight to using VFP forms. Your old screens will still work in VFP, and using them in the short term will help with your migration, but in general the old way of doing things fits badly with the VFP style of programming.

Regarding your point about whether or not to use a DBC, there are pros and cons, and we can have a good discussion about it. But it's unrelated to your current question about browses, so if you would like to take it further, I suggest you start a new thread.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads