> 1. A single EditBox that changes sizes as appropriate. - This will
>require changing the event actions based on the state of the control but
>will eliminate the addressing problems.
> 2. A ListBox that creates and destroys a temporary EditBox. - This will
>require figuring out how to address the properties of the boxes from each
>other.
> 3. A Container with a ListBox and an EditBox that toggles between
>visible and invisible. - This will require learning how to use a
>container object and seems more complex.
>
>My goal is to have a reusable class with the functionality I need. It is
>also to learn how to work with VFP classes. Most of the replies I have
>gotten suggest the third approach. At this point I see it as forcing
>even more learning before success but it may still be the best/quickest
>approach. Is this a case where any one of the three approaches can work
>equally well and personal preference/experience determines the best
>approach or do 1 or 2 have flaws that mean they need to be abandoned?
Hi Joe,
I would say that the container is the best approach.
You want something you can just drop on a form, and the container can
contain everything you need in one object.
You can construct the thing visually. Just edit the container and drag and
drop the controls into it. This establishes the relationships between them.
Also, it is actually less complicated than the other approaches. It takes
the place of the form you're using now. Basically, you put almost all the
code into the container and have your textbox, editbox, and list control
all talk to the container. The textbox tells the container that it's
received a numeric operator; the container tells the editbox to appear and
add a line. Think of it as a "mediator" or "controller" (I get points for
terminology for those words! :)) The editbox notifies the container when
it's got everything needed for the calculation. The container does the
calculation and passes the result to the textbox.
In this case, the container will be referenced from within the other
controls as .Parent. As in something like this (just examples; not
recommending anything and I'm sure it could be much more elegant):
textbox InteractiveChange()
LOCAL contents
contents = THIS.Value
IF "+" $ contents OR "-" $ contents
THIS.Parent.AcceptOperator(contents)
ENDIF
container AcceptOperator()
LPARAMETERS cText
IF [whatver about cText]
THIS.textbox.Visible = .F.
THIS.CalculatingEditbox.AcceptInput(cText)
ENDIF
CalculatingEditbox AcceptInput()
LPARAMETERS cText
IF NOT EMPTY(THIS.Value)
THIS.Value = THIS.Value + CHR(13)
ENDIF
IF [whatever about cText]
THIS.Visible = .T.
THIS.Height = THIS.Height + [whatever]
THIS.Value = THIS.Value + whatever..
THIS.Parent.Calculate(cText)
ENDIF
Containter Calculate()
LPARAMETERS cText
LOCAL result
* Parse
* Parse
* Parse
THIS.Textbox.Value = result
THIS.Textbox.Visible = .T.
THIS.CalculatingEditbox.Visible = .F.
Doing it this way makes it very easy to make changes at each step of the
process.
You may find that your textbox and editbox also need to be subclassed
before they can communicate effectively with the container. For a situation
like this, I'd have them, along with the container, in the same .vcx file
(I agree with those who use .vcx for visual subclasses).
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://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.
