createCustomObject

[Assembly]

i used createcustomobject to mave a PIO that combines two of my other pio's.

on insert nothing appears on the layer. edit a parameter and the objects nested in the new PIO become visable.

This is a useful function.

how do I get it to generate properly on insert?

anyone know what these do?

EnableParameter

SetParameterVisibility

[panta rhei]

i used createcustomobject to mave a PIO that combines two of my other pio's.

on insert nothing appears on the layer. edit a parameter and the objects nested in the new PIO become visable.

This is a useful function.

how do I get it to generate properly on insert?

I'd try an additional ResetObject() in the Combination Special.

anyone know what these do?

EnableParameter: When set to FALSE, the parameter cannot be changed by the user and this is manifested by graying the value. Useful eg. when a field is, depending on circumstances, used either for displaying a calculated value or entering a value.

SetParameterVisibility: When set to FALSE, the parameter is hidden altogether. Useful in complex PIOs with too many parameters: some can be hidden when not relevant for the use. Can result in a confusing interface.

[Assembly]

thanks.

[Assembly]

wait...

rest object did not work, my pio still does not draw on isert, only after an edit.

anyone else?.

[ccroft]

I have never tried to nest one PIO within another, but from what I've read it's not all that predictable, and according to some folks not advisable. There are usually ways around it.

One thing I seem to remember is that there has been some success with a point PIO nested within a Linear PIO, but that a point PIO within a point PIO does exactly what you describe.

resetObj doesn't reset anything until the script is exited. On the first insertion of the PIO, nothing exists which can be reset until the script is finished. At least that's how I understand it...

You might be better advised to hard-code the geometry of the child inside the parent, or to use $Include.

[panta rhei]

I have several of such PIOs, point & path. They've been perfectly predictable.

For such a configuration to make sense, there has to be a legitimate logical (or geometrical or positional) connection between the component PIOs, so that they can exchange information & inherit properties.

One of my problem PIOs in this respect is one where I nest three PIOs inside one, without sufficient shared/inheritable data. Altogether these four have over 130 parameters, of which only some are inheritable, shareable or derivable.

The user interface, OI (very much work in progress), is really problematic. It would be easy to split it by PIO, but that would not make much sense to the user. Splitting by workflow/decision-making would be ideal, but the combinations of simultaneously visible parameters changes in the course of a project. Even that can be technically handled, but for the poor user ? a mere mortal ? this is likely to be confusing.

Anyway, Assembly: do you create any geometry in the ?main? PIO? Try placing even a locus.

[Assembly]

yes i have placed a locus so i know where the main (Parent)pio is. it draws fine.

History.

I have a WallSection tool that draws timber framing, bottom plates, top plates, studs, lining, cladding, insulation. Medium complexity script. Very useful for quickly putting a section togeather. it is a line PIO. I have found on the last couple of projects that I have to ungroup the tool, so that I can edit the parts when it came to detailing. The ungrouped tool becomes static lines and rectangles... So I then start to draw with other custom PIO's FramingPIO, PlyPIO etc etc.

As a note I draw this in a symbol with the bottom plate at the 0,0 point. The Y value of the top plate then tells me what my RL to FFL is which I find very useful.

I like the controll I get in the symbol. So instead of using a line object, I started out scripting a new point object. At the same time I started building into it the ability to draw an Aluminium Window in section, with all the detail our building code requires.

I structure my tools such that all components are defined Procedures, then Begin and Call the procedures. I worked it to the point where the PIO will draw the timber work, The building wraps, the cavity with closer, the cladding, the window head flashings with second layer of building wrap, and the cladding with its flashings.

I started on the aluminium window section by exported a script with the detail window section drawn in a symbol, cut and paste the polylinescript. One profile is a polyline of 100's of points, so to keep TimberSection script clean I started a new PIO to create the AluminiumWindowProcedure.

It was then I wondered if it was possible to nest the two components into a new PIO.

In terms of parameters it is all pretty straight forward.

Topplate,

Windowsill

Windowhead

FrameSize.

The script takes care of sizing most parts.

The Parent PIO once regenerated work perfectly. The best part is that it can be ungrouped, leaving the childern PIOs. To me this has great potential. All the mini procedure -ie Head Flashing. Sill Flashing framing could be child PIO's to, so for special situations the script can rough out the section, it can be ungrouped and instead of dumb polylines I can then tweek the components.

So now if only I can get it to draw correctly on the insert.

[panta rhei]

Curious. I double-checked this PIO that has three nested PIOs and it works just fine.

(Found also another user interface issue...)

[ccroft]

I was just relaying some stuff I read in Vscript List that I had made notes on.

Somebody there a while back said they had this very regeneration problem with a point PIO as parent, but not with line PIO with parent.

Assmembly-man: Maybe the handle you're giving to reset isn't correct. Are you using GetCustomObjectInfo?

[Assembly]

Maybe the handle you're giving to reset isn't correct. Are you using GetCustomObjectInfo?

i'm not at my script, but you might be correct. i was lazy and used lnewobj as the handler. that is likely to get an object from in the childpio and not the PIO itself

[panta rhei]

I was just relaying some stuff I read in Vscript List that I had made notes on.

Charles,

It was not my intention to dismiss your information! Creating PIOs with VS is often voodoo: sometimes they work, sometimes they don't.

Petri

[ccroft]

Petri,

Amen to the voodoo comment.

And my apologies if I took or gave the wrong tone. (I guess I'm still a bit nervous when speaking with the 'Hellion of Helsinki' :-)

Assembly: Let us know how it goes.

To any others reading along: It's a good idea to use something like:

GetCustomObjectInfo(objName,pioHandle,etc,etc);

if IsNewCustomObject(pioHandle) then ResetObject(pioHandle);

to avoid unnecessary regenerations in instances of the PIO that have already been placed and which, god willing, are already displaying properly.

Note that Reset raises a flag that the vectorscript handler for the program at large sees after the script has finished, and then it does the regen. So using reset to try to regenerate geometry, and trying to act on that before the script is exited won't do anything. In Assembly's case the flag may be getting lost in 'the kid's room' so to speak.

[Assembly]

PROCEDURE Insertother;

Var

PIOHandle: handle;

PIOrecordhandle: handle;

PIOwallhandle: handle;

hobject: handle;

hframe: handle;

width:String;

PIOname,

objectname,head,sill:string;

BEGIN;

locus(0,0);

sill:=num2str(0,psill);

head:=num2str(0,Phead);

width:=num2str(0,pwidth);

objectname:='AluminWindow40';

hobject:= CreateCustomObject(objectname, 0,0,0);Hmove(lnewobj,0,0);Resetobject(lnewobj);

SetRField(hobject, objectname,'sill',sill);

SetRField(hobject, objectname,'head',head);

SetRField(hobject, objectname,'width',width);

objectname:= 'SectionTimberCavityWindow';

hobject:= CreateCustomObject(objectname, 0,0,0);

SetRField(hobject, objectname,'sill',sill);

SetRField(hobject, objectname,'head',head);

SetRField(hobject, objectname,'width',width);

objectname:='Framing';

hobject:= CreateCustomObject(objectname, 0,0,90);

SetRField(hobject, objectname,'framewidth','40');

SetRField(hobject, objectname,'framedepth','width');

End;

RUN (Insertother);

[Assembly]

Above is the original script cut and paste.

very strange behavior.

Test 1

I insert (#1) PIO I only get the locus.

I insert (#2) PIO, (#1) draws?!.

Test 2

I insert (#1) PIO I only get the locus.

I draw some lines and other objects

I insert (#2) PIO, (#1) draws.

Now to try CCrofts suggestions.

[Assembly]

This is how I changed it:

PROCEDURE Insertother;

Var

PIOHandle: handle;

PIOrecordhandle: handle;

PIOwallhandle: handle;

hobject: handle;

hframe: handle;

width:String;

PIOname,

objectname,head,sill:string;

BEGIN;

IF (getcustomobjectinfo(PIOname,PIOHandle,PIOrecordhandle,PIOwallhandle)=TRUE) Then locus(0,0);

sill:=num2str(0,psill);

head:=num2str(0,Phead);

width:=num2str(0,pwidth);

objectname:='AluminWindow40';

hobject:= CreateCustomObjectN(objectname,0,0,0,False);

SetRField(hobject, objectname,'sill',sill);

SetRField(hobject, objectname,'head',head);

SetRField(hobject, objectname,'width',width);

objectname:= 'SectionTimberCavityWindow';

hobject:= CreateCustomObjectN(objectname,0,0,0,False);

SetRField(hobject, objectname,'sill',sill);

SetRField(hobject, objectname,'head',head);

SetRField(hobject, objectname,'width',width);

objectname:='Framing';

hobject:= CreateCustomObjectN(objectname,0,0,0,False);

SetRField(hobject, objectname,'framewidth','40');

SetRField(hobject, objectname,'framedepth','width');

Resetobject(PIOHandle);

End;

RUN (Insertother);

[Assembly]

Note also now I used CreateCustomObjectN,

This allows me to suppress all the nested object parameter settings on first insert.

Still no joy and only stranger behavior.

Starting in a new file on first insert objects created on the 'None' class appear for the first instance of the PIO inserted.

On the second insert only the Locus shows up.

So I created a menu script to add all the classes for the objects nested.

First insert the PIO shows up... but again second insert only the locus. Third insert generates the second... and so on.

???.

[C. Andrew Dunning]

Assembly -

A few questions:

- Your signature notes 2 different versions of VW. Are you seeing this odd behaviour in both?

- If you're only having the problem in `09, are you running the current update?

- Are your child objects event-enabled?

One of my PIOs uses a similar approach to create parent/child objects. Both the parent and the children are event-enabled. In one of the early releases of `09, I was having issues not unlike yours. NNA fixed a bug, but in the mean-time, turning off the event enabling fixed things @ my end.

Not sure if that helps, but something to consider...

[panta rhei]

Still no joy and only stranger behavior.

Right. I can't see where the problem might be! Your code looks OK. Unfortunately, I can't make valid comparisons to my PIOs of similar kind, because they are ?event-enabled?. (Did I mention voodoo? Well, event-enabling is santeria.)

This works here:

kResetEventID:

BEGIN

IF P1 THEN MakeThingOne;

IF P2 THEN MakeThingTwo;

IF P3 THEN MakeAnotherThingWithThingTwo;

IF P4 THEN MakeThingThree;

PlaceLoci;

IF P5 THEN DrawSomething;

IF P6 THEN DrawSomethingElse;

END;

(I'm inserting a number of instances of PIO2 twice.)

[ccroft]

In the test of InsertOther without Reset, when you place it the second time it regenerates the first instance. After that things run smoothly. (or do they?)

In the the test WITH Reset, the thing draws properly when first inserted, IE when it's a new object. After that it behaves strangely.

IF both of the above statements are true, it seems the next logical step would be to try:

if IsNewCustomObject(PIOHandle) then ResetObject(PIOHandle);

But it's not clear to me from the first post about test results (no Reset) if instance #2 displays correctly when it's placed. If you get that #2 regens #1, #3 regens #2 and so on then I don't see how this bit will help.

[MullinRJ]

Assembly,

???Have you tested that "hobject" has a non-NIL value after CreateCustomObjectN() is executed? Your code gets executed several times when it is first placed. The order of events is very cryptic, to say the least. Tracking down when things happen is almost fun.

???Next question; on the line before Reset() you have:

??????SetRField(hobject, objectname, 'framedepth', 'width');

Shouldn't WIDTH be unquoted, as it is in all the other SetRField statements?

Raymond

[Assembly]

So I tested these PIO in 2009....

IT WORKS!.

i even get the dotted screen image.

I will need to test it in a few instance before I have full confidence, but from this evening I think this is a could be very useful.

[Assembly]

Assembly,

???Next question; on the line before Reset() you have:

??????SetRField(hobject, objectname, 'framedepth', 'width');

Shouldn't WIDTH be unquoted, as it is in all the other SetRField statements?

Yes it should, thank you.

I will note though that once the parent object had regenerated the script did execute without any problems, so do not think this was a cause of the problem. I did try removing and adding different combinations of child objects and use of the frame object with this error did not make a difference.