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. 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 |