Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Why you need to upgrade NOW
Message
De
17/09/2001 04:15:55
Walter Meester
HoogkarspelPays-Bas
 
 
À
17/09/2001 00:07:04
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00556772
Message ID:
00557194
Vues:
48
Hi Al,

>>Once again, look at Intellisense. It alone is worth upgrade.
>
>I fully agree that if there is one feature that looks like it should be worth the upgrade, it's Intellisense. And yes, it appears to be useful to novice developers and to developers of all other levels.

I'm not that impressed by intellisense. Though it is absolutely usefull for the developer, It does not bring anything new for the users and that's what we really need.

further I fully agree with your statement that it is dangerous to implement wishes from a few guru and don't adress the obvious. More support for the web is fine, but as I see it the majority of the VFP community (see a recent survey here on the UT) is not doing major things with the Web nor n-tier.

A few thoughts of what VFP 7 could have implemented.

1. Rushmore optimization of filtered indexes. (Could boost rushmore enormously in certain situations, especially in large tables)
2. Implementation of a table property to effectively hide DELETED() records and let all VFP commands scope to that one (So also Rushmore and INDEX commands don't see the deleted records) giving less problems with primary keys uniqueness violations and more performance.
3. Support of full index queries (Currently only implemented in the COUNT command) in which tables are not read but only the indexes are used (like in SQL server).
4. Advanced tuning setting in rushmore optimizable commands. (Give optimizer hints to which index to use or not to use)

5. Grids: have the possibility to place three dots after incomplete field info when the comlumns are too narrow to completely show its contents (As seen in many other applications).
6. Grids: Have the possibility to have a fast solution for highlighting the current active row (this means, not by using the Dynamic ... properties).
7. Header, columns, session etc. classes. Allow them to be designed in the class designer.
8. Headers. Add a tooltiptext property.
9. Data environment: Alow them to be subclassed and/or formclasses to contain a dataevironment.

10. Status bar. That Ugly useless thing should be more customizable in what panes to show and what messages to display OR make it much easier to use the ActiveX statusbar and display all statusbartext messages in it (From menus and other objects)

10.a Hooking into Desktop events (like resize) natively.

11. Get rid of the enourmous waste of space in some file headers (Index files (CDX) and Memo files (FPT)). They contain much unused space which on slower networks do cause enormous delays. If you design a table with about 15 or 20 indexes the index starts at about 60k when the table itself is empty.

12. Get rid of that shamefull piece of RI code in VFP 3-6. As others (JimB) and myself have showed, this can be a lot better.

13. Add new features to effecively replicate changes to another databases without the need to buy 3rd party solutions or to write massive amounts of code. Its a real shame that SQL-server and Access do have this while VFP does not.

14. Give a possibility to display a custom Splash screen at the start of your program before the runtime loads and without adressing additional parameters in the commandline (Maybe in the config.fpw) so users get an inmediate response that the application is loading, so that they not going to wonder if they started the application or not and start it two or more times.

15. Faster loads of tables, by having the possibility to adjust the readbuffer.

16. A way to inmediately refresh the readbuffers (See SET REFRESH ,x and without having to use LOCK and UNLOCK).

17. Live views. Views that are in fact live data in which the relations (=joins) are done by relating existing indexes (much like accomplished with SET RELATION). These views load inmediately (because no SQL-Statement have to be executed) and always reflect the current data. They load data when needed (like in a browse) so work very well on large datasets.

18. Have the possibility to share a open table or view with other components (even trough the boundaries of COM) to have a more OOP approach in using tables and views. This gives enormous posibilities to write n-Tier /DCOM applications
without having the disadvantages when reverting to passing offline data between components (Like XMLs CursorToXML and XMLtoCursor)

19. Building Applications. Give the developer the possibility to get rid of all sourcecode in classes and forms, but with the possibility to get the lineno when an error occurs. As I have reported before there technically is way by replacing all methodcode with a '*' and then build the application without recompiling, this is not practical in the majority of cases. If this is not easy to implement, I'm president George W Bush.

20. Compress all table like resources (like forms, classes and reports) when building applications. This reduces the size of an avarage application with more than 70% !!! When running the applications they can be decompressed in memory.

This is what we really need, and have needed badly in the past. I'm sure others could add the list with more usefull things (thus not: OO menus, Native compiler, etc). I think VFP 8 should adress this things first before moving forward tenhance the tool more widely.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform