Thanks for the reply Ken, Conceptually I think the container approach makes sense but it seems there are several problems in implementing it. 1. My testing seems to show that the size of the contents cannot exceed the size of the container. If this is correct - the container will overwrite the other controls on the form at design time. 2. I don't see a way to design the form with just the TextBox showing at design time. 3. I don't know how to tie the TextBox height and width to the container height and width. Are there ways around these issues?
Thanks - Joe On Monday, January 05, 2009 9:18 PM, Ken Dibble wrote: >> 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? > >Date: Mon, 05 Jan 2009 21:18:53 -0500 >From: Ken Dibble >To: [email protected] >cc: >Subject: Re: Rethinking: accessing the properties of a parent (newbee) > >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 > > > [excessive quoting removed by server] _______________________________________________ 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.
