kiwi

As anyone develop PIO's with control points parameters? I'm getting problems to set the parameters to other values than the default ones during the first plugin run... he seems that during the Run() those values are constants set to the defaults values. I've try SetRField() inside a IsNewCustomObject() dependent statement, but the debugger shows no change on the PControlPoint01X and PControlPoint01Y values. The PIO works find, but the first run is a disaster since the control points are not placed where they should... I need to rescue them manually and place then at they respective locations. There is no way to define a good default values (I have 4 control points): the PIO draws anywhere at any scale or any shape! Thanks,

You may don't need a VS key stroke... you can reach must of the menu comands ussing the function DoMenuTextByName().

Set a boolean or a controlling variable for your event menu option ( I use a radio buttons parameter) , and set the event inside a IF (or case with more than one option). The update will always happen, but you can decide what part or functions of your code are running.

I recommend BBedit... he doesn't have a specific VS function research, but the syntax coloring is extremely helpful: the functions names turn blue once spelled correctly. The glossary is priceless, you can set all your common structures and procedures and use a single click to insert them on your code. Most of my work is done this way: get a handle on mouse click, a WHILE statement, own brew offset procedure... a single mouse selection and the debugged code is on your script. For myself I use BBedit on one screen and Safari on the other, the glossary is normally set by class and slowly I've learn most of the functions. But as my libraries grow I recycle more and more code increasing productivity. The winer would be a semi transparent widget... I may work on that!

"Could I use "SetName" using the handle to a layer?" Sounds like the right thing to do...

Going too fast as usual I agree on the correction... Thanks Raymond

Sorry: an easy insight into VS functionality.

They are many ways to do this, but this script keep the normal operator logic: -ask for a scaling factor -memorizes all the selected objects -deselect everything -select each object to apply the scale factor -reselect everything to keep working It works (so far!), and is an easy insight into VW functionality. code: Procedure Individual_Scale; {debug} VAR x,y: REAL; h: HANDLE; i,j: INTEGER; MyH: DYNARRAY [] OF HANDLE ; BEGIN x:=RealDialog ( 'enter a scaling factor','0.5'); y:=x; h:=ActLayer; j:=NumSObj(h); {how many objects} ALLOCATE MyH[1..j]; {allocatating the memory} h:=FSActLayer; FOR i:=1 TO j DO BEGIN {this keep on memory the objects handle} MyH:=h; h:=NextObj(h); END; DselectAll; {we deselect everything} FOR i:=1 TO j DO BEGIN {this select each object and apply the scale procedure} SetSelect(MyH); Scale(x,y); SetDSelect(MyH); END; FOR i:=1 TO j DO BEGIN {this select all the scaled objects} SetSelect(MyH); END; END; RUN (Individual_Scale); [/code]

I use a thumb drive one... it was the only usable one I found the day I star to feel the "mousse syndrome". I know is not the best (microsoft) but I like the thumb accuracy and the way my hand rest on the more than generous ergonomic surface. One side the thumb, and the other with the scrolling wheel and 4 buttons for the rest of the fingers. A couple of days to get use to it, but big productivity gains! I still need to try a finger tip one, but at the moment I'm more than happy with what I use. My best trick is to spin the ball to send the cursor across both screens, and stop it just on the right point... impossible with the mouse, my table is not big enough and I'll need to do this annoying thing of lifting the mouse a few times to get where I want!

Get a trackingball... multi-buttons, wireless, fast, deadly accuracy, and forget mousse related pains... specially if you use big/multi screens

English is not my native language, and I hardly manage to badly express myself... I can only accept your explanation, and agree about the polynomials passing though the control points. But this means that the spline doesn't follow the polynomials? this only confuses me, since the polynomials are the spline definition... a bit like if an arc is defined by a center and radius, but the arc drawing end up with a different curvature. As a graphical definition, any cubic spline point should respect the polynomial definitions, and if the control point respect the definitions it should be part of the spline. I do agree there will always be some delta factor, but on this case he seem disproportionate, and he raises the uncertainty when verifying the accuracy of some algorithms I'm developing in VS aiming to emulate cubic splines. I'll run cubic splines on Mathlab and other CAD software to see how they behave... It may should have been the first step on my understanding, but again I'm just learning and seeking answers on my dealing with polylines.

From Mathwold "A cubic spline is a spline constructed of piecewise third-order polynomials which pass through a set of m control points." Draw a 3 sided polygon, duplicate and you'll see that if you change the second vertex to a cubic vertex (or smooth cubic) the graphical representation doesn't mach the mathematical description... the curve doesn't pass trough the cubic bezier (zoom in). Now draw the line between the first and the third vertex, and another one from the middle of this last one to the second vertex. On the IP multiply the last line length by two and place a locus at the new end point. Now draw a polyline using our locus as bezier point and the precedent start and end points... on this case the cubic representation is close correct. I say "close to correct" because on a earlier post (on the vectorscript forum) I notice that in VW the bezier splines representation doesn't follow perfectly the De Casteljau's algorithm (only for parameters 2^x). I may add that the split tool doesn't show regular result's when working on polylines. You can find points where the tool doesn't work properly, and the results vary with the selected mode. I found this one splitting a couple of hundreds of plolylines... he seem that time to time I hit on the wrong spot forcing me to complex maneuvers to get the job done. So far, even if annoying, this facts where not a real problem. But the cubic representation lack of accuracy is not acceptable... is way of range, and it becomes difficult to mach objects form a graphical point of view.

I must say that press the key combination control+c do exactly the same with out the need for scripting

I'm having a similar problem, with a script forcing VW to crash after running it a few times and zooming or modifying the drawing in any way. Even after a single run, I know that soon or later the app will quit. I never found a cause, but the 2000 lines of script compiles and debug flawlessly... the only message I get is the "reassign a dynarray could cause the loss of data". At the moment I'm working on a new version with a new approach trying to overcome the problem. But I will look a the overlapping variables to see if is the cause!

Try this: code: DoMenuTextByName('Cut',0); [/code]