Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Going beyond the bounds of good sense with a grid?
Message
De
07/01/2000 05:27:10
Cetin Basoz
Engineerica Inc.
Izmir, Turquie
 
 
À
05/01/2000 13:47:56
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00313374
Message ID:
00314386
Vues:
44
>I am developing an application for a trucking company and am starting to work on a dispatch form. They are currently using Excel to display the information that they use but this has several drawbacks. To me this suggests a grid but the problem is that they need to see so much info about each job (including the 20 trucks assigned) while displaying as many jobs as possible on the form that it needs display more than one row per record. I have started playing with custom controls to locate more than one text box in a container which I can then place in the grid but since I have never seen or heard of anyone doing this I have the feeling that I am going to discover something ugly or am overlooking an obvious alternative. Any thoughts?


Hi Jeffrey,
Seeing it's a long thread and being a grid fan couldn't resist putting my 0.2 cents :) My detailed thoughts about this would span several pages, I'll try to keep it very short.
Grid in grid and container in grid works but harder to make them work as you want compared to other form objects. For grid in grid, I suggest you completely plan and work with the child grid separate at the beginning. After you get what you want with it, make it a class, strip recordmark, deletemark etc, set splitbar .f. then put as a control in a new column of parent. Otherwise managing it directly in parent grid is hard IMHO.
For textboxes select on entry problem, having a this.setfocus() in gotfocus() or click helps (although actually grid.textbox.gotfocus() fires twice w/o this code too - it's a confirmed bug by MS). Mouse clicks in a grid are challenging for they are not actually as stated in online doc. You should experiment with it first (I mean it's different when grid has focus or not and different when grid has focus + you click on active cell or some other cell).
If you have to change rowheight, do it when grid do not have focus, otherwise you should well control it to prevent "record is out of range" errors. IOW sizing containers in a grid on the fly is really tricky (IMHO).
Flexgrid and hierarchical flexgrid (treeview like grid with +'s) are supported in VFP as activex controls using ADO. ADO loading is relatively slower but not very slow as I could test.
Dynamic* set are powerfull properties of grid and work quite well when used with sensible expressions. Managing expressions sometimes become hard so when need arises use a UDF call instead of "iif(...". Do not undertake DynamicCurrentControl :) Since you're going to do something not seen daily it might be a valuable tool for you. (As a side note : VFP is kind enough to optimize dynamic* for visible part - IOW a dynamic* for 100 recs or 1 million doesn't noticably differ in painting performance).
Making the grids multipl (parent-child-grandchild) and a supporter view based summary grid could be an option. I did this when I had a need to view-edit data between parent-child-grandchild-grandgrandchild including support for drag&drop between them. A fifth grid was view based (RO) and showing all-in-one info with a tracking of other grids as rec pointer moves.
Only having few fields in grid and rest in a container outside of grid is a good option in cases. Then the container is more managable. You could even mimic grid with a series of containers that are not in a grid. Here is the idea is to have multipl copies of the same table-view in DE and bind each container to a different one. Tables are related as recno()+1 to next (a tricky one relating others using recnos). So as grid navigates, containers have data from recno(), recno()+1, recno()+2... Here the problem is added buffering issues and honestly is not as easy as it sounds to manage.
Floating tooltip like controls are options to show more data :)
Force maximum resolution usage before you start to design IMHO (IOW if they're ready to use 1280*1024 do not try to squeeze all into 640*480).
If they're already doing it excel, it could be a basis for design. And/or VFP+Excel combination could free some screen real estate :) (As a note: At least with VFP6 SP3, Excel2000, Win2000 tested - you can put toolbar and buttons in excel and control their click etc events from within VFP with VFPCOM).
On a generalized subjects like this it's hard to directly help but as you go on and need help in specific areas UT members will be here. Go for it.
Good luck:)
Cetin
Çetin Basöz

The way to Go
Flutter - For mobile, web and desktop.
World's most advanced open source relational database.
.Net for foxheads - Blog (main)
FoxSharp - Blog (mirror)
Welcome to FoxyClasses

LinqPad - C#,VB,F#,SQL,eSQL ... scratchpad
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform