Methods for Dynamic (runtime) created objects

sridhar412

See faq184-928 HTH

Chris

sridhar412:

I just happened to be working on something similar all day.

If I understand your query correctly, you are trying to write method code to
controls at design time and maybe at run time.

* Some self back patting…
I created a database that resides at home ()+"cust_cntrls.dbc" which holds a number of tables for creating custom controls at design time. Basically a mini-framework.

I decided to write all the code for the custom controls and their associated method code as database stored procedures.

*

Now to your specifics:

First you have to get a reference to control(s) in question.

Second use the referenced controls’ .writemethod() i.e. oObjRef.WriteMethod(cMethodName,cMethodCode)

Since you said this will be a dynamic system, it will be easiest to use the _screen object to access the control(s).

i.e. _screen.forms[x].controls[x].writemethod(cMethod,cCode)

-or-

oObjRef = _screen.forms[x].controls[x]
oObjRef.writemethod(cMethod,cCode) && for code line brevity and readability

This won't work on instantiated (running) objects - only at design time.

VFP 7 allows you to write method code at run time I believe, but I'm still on VFP 6. Oh well...

Even if you’re are not using VFP7, here’s some code that generates a
form at on the fly, adds a textbox, and writes method code to the textbox’s click method:

create form Test nowait
_screen.forms[1].addobject("Text1","Textbox&quot
_screen.forms[1].text1.writemethod("Click","lnOne = this.value&quot

Voila!

Basically a run-time design environment, which may be, used for on-the-fly app customizations.

(note: there are other methods of getting a ref. Aselobj(), sys(1270) on a mouse down in a running program, etc., but you did specify dynamically generated and these other methods just don’t seem to fit the bill.)

Hope helps,


Darrell
'We all must do the hard bits so when we get bit we know where to bite'

Sridhar

I am working on a form designer for Data entry jobs, which
uses objects (combobox, textbox etc) created dynamically.

How to do it without using a class?

Creating an object by code always uses a class at somepoint for example :

The above sample uses VFP's base class. You can also take this base class and modify it to suit your need by using DEFINE

And you can further modify and add objects to your form and build a form, but everything is based on a class (wether is VFP's or your own)

Mike Gagnon

Mike,

I am naming the dynamic objects like :

Combo1,Combo2,Combo3,Text1,Text2,Text3 based on the
requirement (combo/text). The number of objects is also
variable.

I actually have to define a class for each & in the <procedure>, define the code.

As i have variable number and type of objects, how can i construct the code on the fly and use it with precompiled
program?

Thanks

Sridhar
a new vpf user

sridhar412

See FAQ184-928 - that explains how to add code to a method at runtime.

Why is it important for you to create an application this way?

You have stated you are a new user - it may be someone could advise you on a simpler route if you tell us what you are trying to achieve. HTH

Chris

What i am working on to create an Visitor Pass System with
user definable layout.

Here, the user can define the label, input type (text/radio/combo etc), position etc. Based on this layout, a form is created dynamically.

The layout varies for different type of pass issued. SO, the count and type of input (object) is not fixed.

I wish to program valid, gotfocus methods.

So, how can i write the code for class as number of procedure is flexible?

sridhar

Sridhar

Here is a small sample that might point you in the right direction:






Mike Gagnon

Thanks. Getting hold of it.

Will try and get back with more problems!!

Sridhar

sridhar412:

It sounds like you will need to use a hook object/hooked paradigm.

See the post that ChrisRChamberlain referenced - FAQ184-928 - and Stephen Black's article on hook operations.
Darrell

P.S. why don't you just have generic class objects that call out to code that implements the desired behaviour.

Then, when a custom method is required, you just switch the external code the object calls.

example.

* Generate the form, add custom controls with
* generic calls
. code...
. code...
....
. more code...


* Create or retrieve code that's dynamic
* and save it in the program that the generically
* coded controls will call out to

ExternalProg.prg = strtofile(from somewhere) - or whatever
compile External.prg


** This is slightly out of order, but I think you get the idea...
* On-the-fly generated control placed on a form
* that has generic method code
* ( object/control always calls the same program
* so we just switch the code it runs
* it'll never know the diff... unless we tell it


Textbox.click

do externalprog
-or-
lcGetValue = ExternalProg(parameter list)

do something else...

* end of method 'We all must do the hard bits so when we get bit we know where to bite'

Also, see this article on the compile command.

'We all must do the hard bits so when we get bit we know where to bite'

sridhar412

thread184-357445 is obviously a side issue to this thread, but even at this stage, it would be as well to consider how to create and print the report that's required.

You will need to through the VFP report writer - I don't think there's a way round that.

If, in dynamically creating your form(s), they became the layout for the label(s), then you could dynamically create a report which would be a 'mirror' of the form.

If you created a toolbar class or properties form, you could reposition and resize the controls, change fonts, font sizes, etc on the form through the use of spinners, etc.

When the form looked correct to the user, then you could create the report and run it.

You could print it to paper or a postscript file which could be converted to an image file format if required.

None of this is for the faint hearted, so you are going to have your work cut out! HTH

Chris

sridhar412

What I omitted to mention is that if you were to follow the methodology in the last post, I suggest that when you create a form you create it to the same size as the printed output would be with .ScrollBars = 3.

That will enable you to position your controls on the form so they are the actual size that will be printed. HTH

Chris

ChrisRChamberlain:

You are right about the report writer.
That was my opinion also. But what the hey.

The page layout methodology you are suggesting
seems the most likely to be successful, but it
may be to much work for them if they have a short lead time.

As an additional source of information, check out Doug Henning's article
on FoxTalk from June 1999 entitled - &quot;Report Objects Finally!&quot;.

The root link is here Sorry but the direct link I have includes my User ID.

You can sign up for the free trial subscription; which as far as I can tell is more like permanent;
and navigate to the article I mentioned.

Darrell 'We all must do the hard bits so when we get bit we know where to bite'

An alternative link to that article mentioned by darrellblackhawk that does not require a subscription.


Doesn't say a lot for Pinnacle Publishing's security! HTH

Chris

He He He lol 'We all must do the hard bits so when we get bit we know where to bite'

'Doesn't say a lot for Pinnacle Publishing's security!'

Invalid comment and apologies to Pinnacle - I went straight there via Google.

The article is a freebie, as it happens. HTH

Chris

Sridhar

If you read the last few posts in this thread, you will see darrellblackhawk and I agreeing that the only probable way you will achieve what you want is by using a VFP report.

If we consider the overall design of your application, the report becomes the focal point and we then need to work backwards to determine how to dynamically create the report.

Conventionally reports are created and modified in the VFP report designer - letting a user loose on the report designer is a recipe for disaster and, IMHO, that is not a viable option.

What is possible is to dynamically create a VFP form which would act a previewer/modifier of the actual printable report.

The way that could be done was outlined earlier in this thread.

The main problem you have now will be time - developing an application like that is very time consuming, even if you have done one before.

It will also require a bread of VFP knowledge that you are unlikely to acquire quickly.

What may be possible is to dynamically create a previewer/modifier form, (which is not the current one containing comboboxes, etc), and use it a screen dump to an image file instead. That would be very crude and may not be commercially acceptable.

I would suggest you abandon your other thread184-357445 as that question is inextricably linked to this thread, and await any alternative ideas that others may have. HTH

Chris

Thanks for all your help.

As my time span is short, i have used old fox program type.

After creating a new form dynamically, i placed
the contents using @ ... say command. For bmp image,
@ ... say &quot;filename&quot; BITMAP

Used &quot;scrnprnt&quot; which allows you to print the current form or screen.

Change BorderStyle - 0, Control Box - False, TitleBar - 0 form properties to print without outline box.

As i am new to VFP and comfortable with 'old world' programming (read clipper), i had to use
this to complete the assignment within the time frame.

I have tried earlier to understand the VFP report designer.
I guess, i have to spend lot more time on it.

Thanks again to Chris, Mike and Darrell

Sridhar

ScrnPrnt.Zip from the UT at

Sridhar

The important thing is that you have an acceptable result, not how you came to do it.

Good luck with VFP! HTH

Chris