Hi Gene
I agree, this is a longgggggggggggggg one!
Some thoughts though:
>>I do not use data sessions, binding to tables, or even a database
container.
Too bad. If you were to use private data sessions in your forms, you
would be able to isolate and encapsulate the form behaviour, at the
properties, methods and even tables and cursor levels. The database
container, if you use DBF's should not be used for validations. It is
much better to have your validation routines outside of it. At least,
that is what I do. Others may differ.
>> Validation is using .valid(). I would like to change this to
.LostFocus(). What are the ins and outs?
Why? The valid method is supposed to be used for validation, returning
.t. or .f. or 1 or 0. Lostfocus is used to put code that should fire
when validation is passed.
I almost never return .t. or .f. from a validation method, but 1 (if
valid) or 0 if not valid. If valid, the 1 causes the code to pass
through the keypress first, the lostfocus method after and then jump to
the following control. In the case of a grid, it will jump to the next
column. If invalid (such as for instance the code introduced does not
exist in the table), a return of 0 causes the cursor to stay in the
control and it will not move until a valid code is entered or escape is
pressed (if you programmed the escape key press in the keypress event)
Example of an item code validation in a grid column
if Empty(this.value) or ; && if you use your mouse to click an exit
button or the X at the top right of the form
lastkey() = 27 && Esc key
return 1 && avoids validation in the
following lines, goes through keypress and then through lostfocus
endif
select curInvoice && this cursor is the recordsource of
your grid
Local cCode
cCode = Alltrim(this.Value)
if seek(cCode,'itemstable','codetag')
replace curInvoice.code with itemstable.code,;
curInvoice.descrip with itemstable.descrip,;
curInvoice.price with itemstable.price
return 1
else
this.value = ""
messagebox("INVALID CODE",48,"ATTENTION",2000)
return 0
endif
endif
** keypress event of the textbox of the code column
LPARAMETERS nKeyCode, nShiftAltCtrl
if nKeyCode = 27 && Esc key was pressed
release thisform
endif
** lostfocus event
your code
etc
>> editing
As I understand it, you would have a table with the original orders for
each customer and then reality says some items were overprepared, some
where underprepared (then you have a backlog), etc
If you select the applicable order into a modifiable cursor, place it
into a grid and program code to modify it, then you can save the
modifications directly from this cursor. For this cases, cursor adapters
are your best bet. But you could avoid using CA's if you are not very
familiar with them and use a regular updatable cursor instead. Then you
scan this cursor, read each record, compare with the applicable record
in your table and gather on it. But you need primary keys to make this
work properly. But an iron rule: do not modify the table directly,
always do that in memory by using a cursor.
>> browses
Replace them with grids. You can use colors, enlarge headers and in
addition you can use them to edit the underlying cursor
>> Not Totally Relational
As I said before, use primary keys for all tables. You can use surrogate
keys, that have no relation whatsoever with the contents of the table
but refer to the record itself. This is an absolute must if you will use
cursor adapters or views. If you can't have them, you must design a
scheme that would identify each record uniquely, otherwise your life
will be very complicated when you have to make modifications.
>> This system has to continue operating as changes are made
You know your system, therefore you will have to make changes on the
fly, without affecting the daily operations. If you have to make major
changes to tables, you should try to do them from home, at night, when
the company is closed for work, working remotely (LogMeIn is what I use)
My two dollars (two cents is too cheap for such a long post :-) )
Rafael Copquin
El 24/04/2013 04:54 p.m., Gene Wirchenko escribió:
Dear Vixens and Reynards:
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
