Visual FreePro Requirements

[foxmuldr2]

A few questions. Please advise.

(1) Any reason to keep FormSets? Didn't think so. They're history.

(2) Any reason _screen can't be a regular form (and not the special desktop it is today). I'm thinking VFrP can have multiple _screen objects open at the same time from a single instance, each with its own command window, screen settings, and access to all designer tools, including having instances of a given object open in multiple screens, where you change one in one screen, and those changes are reflected everywhere it's open.

(3) Any events or methods we have today that aren't really needed?

(4) Any events or methods we DON'T have that ARE needed?

More questions on other posts.

Best regards,
Rick C. Hodgin

 

[EzLogic]

it will be nice to have a base class for the textbox that handles the keystrokes/trapping them.
i always have my base class that does that.
example:
standard vfp 9 base class textbox.. if you hit backspace too many times, you loose focuse. hit up arrow, down arrow or space bar too many times.. you're out of there..

so, i had to write my own codes, and added a property to the Valid Event etc..

2- Numeric input on the textbox with the proper input mask is still horrible in VFP comparing to other languages

3- a Super Grid Class would be awesome! VFP grids are a nightmare..

4- a Native Newer Excel support for importing/copy to .. (type xl5 is ollldddd)...

5- Have a native Function for FirstDay() LastDay() (i write my own) useful for reeporting as default date values. .yea, they're easy to write date()-day(date()) + 1 = firstday()

6- I dislike the combo dropdown listbox for VFP.. not nice..

7- a better cursor handling for naming convention and not allowing to overlap with other open forms (if not in private data session)
currently, i use form property and i give them sys(2015) and i close them when in unload.

lcCurARTran = thisform.curARTran && curARTran = sys(2015) in the init of the form

sele * from blabla into cursor (lcCurARTRan)

then in the unload: i cloase (lcCurARTran)

just some thoughts...

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[foxmuldr2]

Ali,

Great suggestions. I agree completely with 1, 2, 3, 5, 6 and 7. Consider them done. I hate VFP's grid class. It's clunky as all get out. I will create a Grid class that provides commensurate functionality for compatibility.

Number 4, excel, will have to be integrated differently. I have some ideas on this, but they will be through a DLL plugin that I'll document at some point in the future. I have to do it this way because Visual FreePro will be multi-platform, and I do not want to pigeonhole myself with OLE/ActiveX support natively. I will provide that functionality natively through source code commands, but those commands will go through a plug-in extension unique to Windows, and another one unique to GNU/Linux, for example.

As for the Super-Grid class:
I will create a new class called GridX which will be the super-grid class. It will allow any object to be gridded at any level, with top-level objects receiving notification through a new event when the grid is activated based on its data set and a redraw event. I will probably call this event "render," which will be a message from VFrP telling it to do whatever is required to draw itself on the screen given the specified X,Y values, allowing it to return information about how big the thing was it drew.

That brings up another point! VFrP will have the ability to return multiple values with a single command:

FUNCTION someFunction
LPARAMETERS tnMonth
LOCAL lnValue, ld1, ld2
**********
* Code goes here, populates three return values:
*****
* Can either use the explicit assignment (anywhere in the function body):
*     caller.lnDaysBetween = lnValue
*     caller.ldStart       = ld1
*     caller.ldEnd         = ld2
*****
* Or a more traditional method for values:
*****
    RETURN lnValue, ld1, ld2


**********
* Would be called using the syntax:
*****
    lnDaysBetween, ldStart, ldEnd = someFunction(lnMonthNumber)

This syntax will allow a feature I've missed greatly in VFP. It will also allow the gridx class to return both width and height information about whatever it drew during its render event, so that subsequent unusual-sized items will be rendered appropriately for the next line, etc.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

How about a KeyPreProcess event?

It is called before KeyPress to allow the running application to intercept and consume that keystroke in some way, to absorb it, alter it, substitute it with an additional sequence to use in its place, the results of which are then sent to the KeyPress event like normal.

If, however, the key is consumed by KeyPreProcess, then no KeyPress event takes place, and no focus change would be attempted, it would be as though the user never pressed a key.

??

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

Two reamrks on VFP features already there to cope with your problems.

1. Leaving a control can also be made harder to do if you SET CONFIRM ON. I also always doubt it's a good idea to differ from standard behaviour, if backspace from an empty control get's you to another control as a backtab does, I'd always be fine with that.

2. No need for KeyPrePRocess, KeyPress is already that, it occurs before a letter is added to the textbox value, for example, youd you can oppress a key via NODEFAULT in it and you can change a key by using KEYBOARD and sending another keypress message that way. You need to be cautious with recursion happening, but that would also apply to KeyPreProcess. And the other meaning of such a preprocessing event would be the forms KeyPress of course.

I would welcome the KeyPreProcess event for another reason: It would be easier to understand and correclty implement than the NODEFAULT logic. Any way I dislike how several events need wither NODEFAULT or can also be canceled out of by RETURN .F. It's a fine difference, and I rather wouold split events where NODEFAULT has a meaning into two events, where you can stop the second part of the event (after hook) in the first part of the even (before hook). All the Before/After events foxpro offers are really nice and easy to use. It wold of course be bad to name the keypress event pair BeforeKeyPress and AfterKeyPress, OnKeyPress and AfterKeyPress would perhaps be ok, whatever nomenclature you prefer, the idea in itself isn't bad for the benefit of clearer coding.

Another event order that is a bit complicated is form releasing, you actually need to know Closable, Release(), QueryUnload() and many pepole are even only aware of Release(). I dislike Release() circumventing the QueryUnload event, I dislike RELEASE WINDOW circumventing it, though if you get rid of the xbase style of windows in the vfp9 mode, that would solve that, rather add to the Releasetype and let every closing of a form go through the QueryUnload event.

Bye, Olaf.