unique object id

Is there such a property? How to access if if available?

object.name could not be unique (when using sys(1270)) once you started
wrapping things with containers.

--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Olaf
Thu Jan 04 06:42:16 CST 2007

> object.name could not be unique (when using sys(1270)) once you started
> wrapping things with containers.

Yes, that's why only the full name, eg
myform.container1.pageframe1.page2.text1
is unique.

With Sys(1270,x,y) you get an object reference,
why is that not unique enough?

Or were you thinking of Sys(1272)?

If you want to have access to anything from somewhere
central, eg. switching language and changing all captions,
I'd rather use a "think global, act local" strategy. Use the
object hierarchy and implement in each class a way to
react to some event or method (eg some property_assign)
and take care about child objects. Then you'd just need to
trigger this for each object having no parent, eg. each form,
which you get by _screen.forms(1) to
_screen.forms(_screen.forms.count).

Bye, Olaf.

Man-wai
Thu Jan 04 06:48:53 CST 2007

> With Sys(1270,x,y) you get an object reference,
> why is that not unique enough?

While going back home in a double-decker bus, I figured out that I could
get around the problem without using an object's GUID. But it's still
more convenient if Foxpro 10 would expose that property... :)

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 20:47:01 up 23 days 2:59 0 users load average: 1.00 1.00 1.08
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Bernhard
Thu Jan 04 06:54:29 CST 2007

Hi Man-wai Chang,

> Is there such a property? How to access if if available?
>
> object.name could not be unique (when using sys(1270)) once you started
> wrapping things with containers.
How do you manage to have two objects with same name as children of the same
container?
Container.AddObject("SameName", "AnyClass")
will throw an error when called twice.

When using Sys(1270), you get a reference to the object. This should be
non-ambiguous.

I came across this kind of problem, when instantiating the same (form-)class
independently, i.e. they are not children of a container. Then they get the same
name, namely the class name. Every such form has a menu. In the menu functions,
one cannot reference this or thisform, also _screen.ActiveForm was not reliable.
But the form can be referenced by its name. So it was necessary to have unique
names for different forms of the same class.
My solution: in form.load I change the name of the instance:
thisform.Name = thisform.Name + Sys(2015)
Now the menu in a form finds its own form.


Regards
Bernhard Sander

Man-wai
Thu Jan 04 07:54:03 CST 2007

> forms of the same class.
> My solution: in form.load I change the name of the instance:
> thisform.Name = thisform.Name + Sys(2015)
> Now the menu in a form finds its own form.

This is surely a solution, but that would complicate the framework I am
developing. No ... thanks. The current way of naming objects is fine,
but there should be a way to access the tree of objects-GUIDs.

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 21:52:01 up 23 days 4:04 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Thu Jan 04 08:13:24 CST 2007

> This is surely a solution, but that would complicate the framework I am
> developing. No ... thanks. The current way of naming objects is fine,
> but there should be a way to access the tree of objects-GUIDs.
>

In facrt, why keep those IDs secret?

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 22:12:01 up 23 days 4:24 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Thu Jan 04 08:22:44 CST 2007

>> This is surely a solution, but that would complicate the framework I am
>> developing. No ... thanks. The current way of naming objects is fine,
>> but there should be a way to access the tree of objects-GUIDs.
>>
>
> In facrt, why keep those IDs secret?
>

Unless... there is no way to tell it during execution .... because of
the inheritance....

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 22:21:01 up 23 days 4:33 0 users load average: 1.06 1.03 1.01
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Fri Jan 05 00:18:17 CST 2007

Man-wai Chang wrote:
>
> Is there such a property? How to access if if available?
>
> object.name could not be unique (when using sys(1270)) once you started
> wrapping things with containers.
>

It seems that I found what I needed: sys(1272,this). It returns the full
"path" to object this starting from thisform.

--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Olaf
Fri Jan 05 05:51:46 CST 2007

> It seems that I found what I needed: sys(1272,this). It returns the full
> "path" to object this starting from thisform.

This was in my post too (as an indirect recommendation).
Be warned though, SYS(1272) will start the "object path"
with the forms name, which, as Benhard said must not be
unique. But as you call it in the context of the object (this)
you know what thisform is in that context and could replace
the form name with something unique.

I wonder how you get the idea there are GUIDs for
every object. GUIDs are generated for OLEPUBLIC
classes, but not the native vfp classes, not that I know
of. And it's not a property of the classes, it's merely
for the registry as a unique id for OLE/COM, but not
for VFP.

Bye, Olaf.

Man-wai
Fri Jan 05 06:01:41 CST 2007

> I wonder how you get the idea there are GUIDs for
> every object. GUIDs are generated for OLEPUBLIC
> classes, but not the native vfp classes, not that I know
> of. And it's not a property of the classes, it's merely
> for the registry as a unique id for OLE/COM, but not
> for VFP.

What about the memory addresses pointing to each object in a form? There
must be a native, unique address to each graphical object in the form.
ANd it may be useful to expose them.

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 19:59:01 up 24 days 2:11 0 users load average: 1.00 1.02 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Olaf
Fri Jan 05 06:41:04 CST 2007


> What about the memory addresses pointing to each object in a form? There
> must be a native, unique address to each graphical object in the form.
> ANd it may be useful to expose them.

you get an object reference with Sys(1270) or THIS.
Why would you want to know the adress in memory?
You gain all access through this object reference.

VFP is hiding those adresses by design to not give you
the same pitfalls fiddling around with pointers has
in C.

You could store references to THIS, if you want, by
passing THIS to somewhere in init() and storing that
parameter as a direct reference. But you'd have problems
with releasing a form, as you first would need to release
every object reference before releasing the form.

So you may introduce more trouble than you gain
profit from that.

Think about oop and encapsulation. An object should
know what to do with itself by itself. The more you
throw around references to somewhere outside of
THIS, the more dependancies you get, the less encap-
sulation you have, which is bad design.

Bye, Olaf.

Thomas
Fri Jan 05 13:40:37 CST 2007


> What about the memory addresses pointing to each object in a form? There
> must be a native, unique address to each graphical object in the form.
> ANd it may be useful to expose them.
>
Vfp has the tendency to shuffle memory around - which is the reason you
have to lock some adresses if you are working in a C-fll.

regards

thomas