Hypertext Resume&references|Business and development   Philosophy|Foxpro Design Strategies|Code Sample| Tool Suites

 

Scott Keyes (830) 964-5803    scott_keyes@yahoo.com   http://www.oocities.org/scott_keyes/index.html

When a client says "I don't care if it doesn't look like an expensive state of the art solution.. I need it now and I need it stable and I need it to do these things" your best bet is still going to be menus and browse windows, and WAIT windows... but you can do incredible things with these if you know how..

For an "in house" application , you cant beat this approach for speed of programming ,maintenance nor especially for how much data you can fill the screen with in a meaningful fashion... It takes a few arcane tricks to control multiple browse windows reliably, make them go where they should and stay there, and update and such, but once you get the hang of it, it is a very very worthwhile technique.

It also can give you an application that will run on every version of foxpro from 2.5DOS to VFP6.0 with nothing more than a recompile... 

This is a screen shot from a small local sample using goofy test data...... using live data they would  relate in a 1 to many  hierarchy from left to right and then down to the bottom screen BUT if you wanted to look through , say Donors, you would click on the Donor screen and then hit the "Focus" menu item/button and then you would see all donation records and the relationships would flow up and down from there. the whole application is context sensitive in this way... you first click on a  panel, say Donations, and then click on the "looks like a menu bar but mostly acts like buttons" bar. If you've hit the ADD button then you'll be adding donations.. or editing donations if you hit that button.
 

(oh yes and using the title bar as a system message bar is pretty easy and catchy too...)

 

Scott Keyes (830) 964-5803    scott_keyes@yahoo.com   http://www.oocities.org/scott_keyes/index.html

 

 

Scott Keyes (830) 964-5803    scott_keyes@yahoo.com   http://www.oocities.org/scott_keyes/index.html

Below is the first part of a sequential series of screens involved in a very desceptively sophisticated data entry operation.
With proper design the data entry for this type of interface can be much faster and cleaner than in conventional form based one... especially because when you develop using browse window you are much closer to the data than with a form, and the data is what its all about..
 

Scott Keyes (830) 964-5803    scott_keyes@yahoo.com   http://www.oocities.org/scott_keyes/index.html

 

 

Scott Keyes (830) 964-5803    scott_keyes@yahoo.com   http://www.oocities.org/scott_keyes/index.html

I am quite capable of writing a  VFP OOP application using nothing but objects and containers from VCX libraries (when these where buzzwords and the "hot" thing I even had requests to do so)... but it would cost you a fortune and be a pain in the neck to maintain AND would take forever and hog PC system resources, ....If you know anything about Foxpro, think about a VFP screen with 5 large linked grids on it, then you'll get the point.. Buzzwords and bragging rights aside , Object libraries have VERY SPECIFIC things that they are useful for and in those things they are very useful... but business is often a game of oneupsmanship and things are used because they are "new" and "cool" and cutting edge, and not necessarily because they are the right tool for the right job...

Again the K.I.S.S. principle is best... I use the simplest most reliable means I can to achieve my ends, and I know I have it right only, when what I've done looks so simple and small it looks like it shouldn't have been much work to get it that way...

Below is a sample VFP5 form I wrote some  years ago. When possible my applications are monolithic in terms of interface... IE they have one main screen, and everything is there so you needn't get lost in the tangled depths of a multi-layerd interface... it actually presents a greater programmer challenge, because getting all that information/controls onto a single form is more difficult. but it pays off in user training time because all they have to know is one screen and everything they could want to know/see/do is right there...

If you havent got a help desk ticket system handy i'd be happy to work this one to your needs.

Scott Keyes (830) 964-5803    scott_keyes@yahoo.com   http://www.oocities.org/scott_keyes/index.html