Hi Stefan,

>Counterexamples:
>
>

= createobject("custom")
>with createobject("custom")
>   * ...
>endwith
>return createobject("custom")

>
>What are the names of the created objects?
>

My guess - none. What would be the point? From the help:
Use CREATEOBJECT( ) to create an object from a class definition or an application that supports Automation, and assign a reference to the object to a system variable or array element.
Without the assignment, of what use would the above be?

>

local o1, o2, a[1]
>o1 = createobject("custom")
>o2 = m.o1
>a[1] = m.o1

>
>What is 'the' name of the created object?

"The" name? I don't follow you here. Is this some form of test? :-)

>As I said, if you need a global name then you need a global anchor of sorts. Fernando's suggestion is the easy to implement and should be fairly robust, especially if you make good use of SYS(2015) where appropriate. If you want to keep the number of global names used to a minimum then a CUSTOM object could serve as a collection (.AddObject your objects to it with a SYS(2015)-enhanced name so that you can access them by name or via the .Controls collection). This registry object would consume only one global name but it could provide any number of globally reachable names for your objects. If you .AddObject the registry object - or your objects themselves - to the global _SCREEN object then they will survive a CLOS ALL and a RELE ALL EXTE. *g*

Could you point me to Fernando's message? Seems I missed it...