Jump to content

MullinRJ

Member
  • Posts

    2,007
  • Joined

  • Last visited

Everything posted by MullinRJ

  1. Tom, Do you set the font face from within your script? I have seen PIO's accept color, font face and size changes by selecting the PIO and using menu options to apply them, but you may have a problem if your script sets them explicitly. Also, what properties are set for the PIO? The one I examined had the RESET button highlighted with no checkboxes selected. Raymond
  2. I'm not sure about your first question. You can change OIP values from within a PIO, but the code has to finish executing to see its effect. When the PIO code starts, the OIP values are copied to memory and essentially become constants for that iteration of the code. New values can be written to the record where the OIP stores information, but they will not be reflected in the OIP window until after the script stops. Depending on how you write your script, this may or may not be an issue. I played for a day with a script that wrote data to the OIP until I figured out the interaction and the sequence of events. I was able to get what I wanted, but it was anything but easy. To write to a PopUp menu in the OIP, you just need to set it to one of the choices already in the menu. Use: SetRField(objHand, objName, 'PopUpFieldName', 'yourPopUpValue'); to set the value. You can get the objHand and objName values from: GetCustomObjectInfo(objName, objHand, recHand, wallHand); "objName" is the PIO name AND the name of the record that defines the PIO values, as you might hope it would be. I'd write more, but I'd only be guessing at what I think you might want to know. If you can be a little more specific, I, or someone else on this board can tell you a whole lot more. HTH, Raymond [ 10-09-2004, 03:06 AM: Message edited by: MullinRJ ]
  3. Hello again Chrissy, As I rode my horse around the pasture today, in the last light of the setting sun (a national pastime in Texas), I gained some more clarity to your problem. If you don't want to use the DMTBN approach, the following procedure will find all the text objects in a dimension object, regardless of how they are nested in groups. Actually, the code will work for any nested group of objects, not just dimensions. I leave it to you to do with them as you will. I always enjoy writing recrusive routines, perhaps because I don't get to use them much. So, here's one that was fun to write. code: procedure xxx; { Get the handles to all text objects within a dimension object. } { Author : Raymond J Mullin - ?2004 All rights reserved. } CONST TextType = 10; GroupType = 11; VAR H :Handle; procedure FindTxtObj(H :Handle); { Receive a handle to a container object. Step in, and look for Text objects. } Begin H := FIn3D(H); while (H<>nil) do begin case GetType(H) of TextType: begin { Do stuff to text here } Message(H, ' ', GetType(H), ' ', GetText(H)); Wait(1); end; GroupType: FindTxtObj(H); { Re-enter this procedure and search the new group. } end; { case } H := NextObj(H); end; { while } End; { FindTxtObj } BEGIN ClrMessage; H := FSActLayer; { Handle to Dimension Object } FindTxtObj(H); Sysbeep; END; Run(xxx);[/code]
  4. Hi Chrissy, Depending on the level of control you desire, there are two ways I know of to do what you ask. The easiest is to use DoMenuTextByName. If you can use one of the point sizes in the menu, just put it's menu index in the following call. DoMenuTextbyName('Font Size', 4); { 12 points } For more complicated processing, you can get a handle to the text element of a dimension object using something similar to the following: code: procedure xxx; CONST TextType = 10; GroupType = 11; VAR H :Handle; BEGIN H := FIn3D(FSActLayer); while ((H<>nil) & (GetType(H)<>TextType)) do begin if (GetType(H)=GroupType) then H := FIn3D(H) { Text is grouped, don't know why } else H := NextObj(H); end; if (H<>nil) then begin Message(H, ' ', GetType(H)); { You have a handle to the text part of the Dimension } { insert your code here } end; END; Run(xxx);[/code] Have fun, Raymond
  5. Well, as is usually the case, confusion clears as I walk away from a problem. I was confused as to why text was grouped inside a dimension object, but I was only thinking of the single numeric object that represents the dimension length. In a simple dimension, there is only one text object within the dimension object, the length of the dimension. It seemed unnecessary to group it. However, dimensions can be made more complicated by adding tolerances, leaders and/or trailers in the OIP. Each of these text objects can also be found inside the group within the dimension object, if they exist. So, once you have a handle to the first text object within a dimension object, you may have to search for additional text objects to format. The number of text objects can be determined by the setttings in the OIP that control the dimension object. I hope this makes sense to you. Have fun, Raymond
  6. I have never found a use in my work for placing a script in a View, except for running a quick and dirty one time script without creating another VS routine on a palette. Just because something is available, doesn't mean it needs to be used. The original question asks, "Why is this useful?" Patrick may have some appropriate applications, but for the most part, it's not an integral facet of VW. However, it is a nice feature if you can find a use for it. Raymond
  7. Your questions are valid, but I don't believe they are documented. I think they would best be answered by attempting explicit examples. quote: ...would you add a stand alone script with its own set of variables, begin, end, and run, statements?Yes, unless you don't use any variables. Then you can just have some statements without Begin, End and Run. Treat it as a normal script. quote: Would the added script execute before or after the actual edit sheet script?Before. I just tried a quick example. quote: If you add something contradictory to the edit sheet script itself, would it replace that item in the script, would it generate a VectorScript error, or would it just ignore it? When you say contradictory, what did you have in mind? Raymond
  8. Robert, How big are the files? I have most of the old versions. If you would like to send me the files offlist, I would be happy to translate them to a newer version for you. You can send them to this screen name at AOL.com Raymond
  9. Sorry Patrick, I just now saw your post or I would have replied sooner. I too am sitting on the bench waiting for a definitive need to get started. Most everything I have wanted to do can be done in VS, except the little mode icons that appear in the display bar of well polished tools. Give me a good reason and I'll join you. Most likely, two can work better than one. Nudge, nudge. Raymond
  10. Sorry, I don't know how to do 01, but if the font is carefully chosen O1 (the letter "O") will work. Of course, it won't sort very nicely with other numeric strings. Raymond
  11. You could use the Mdash (option '?' on a Mac) character and 12?15 will be seen as text. [ 09-17-2004, 05:31 PM: Message edited by: MullinRJ ]
  12. Hong, I am not sure if this is pertinent, but I have deduced some behavior in programming PIO's that I recently found confusing and undocumented. The pParameters of the PIO act as constants during the execution of the PIO code (i.e., you cannot write to them). Though you can write to the record where they are stored with SetRField(), the new values you place in the record are not available to you until the next time the code is executed. I believe all the PIO pParameters are copied to memory before the script executes and are not updated again until the script is reexecuted (from moving, resizing or changing the PIO parameters in the OIP). When you reference a pParameter, you are not getting the value from the record, you are getting it from the copy that was made before the start of your script. Since you probably want to access your values as they change within the script, don't access the pParameters directly. Copy them all to temporary values (script variables) at the start of your script and work with those (same technique they use). You can update the PIO record at any time, but also update your temporary variable and always work with it. This caused me several hours of head scratching one day until I sorted it out. HTH, Raymond
  13. Ziska, How many logos and how complicated are they? If you could you send me one, perhaps I might be able to help. I won't really know without seeing the exact format of your data. Raymond
  14. You can also use the Move command once the vertices are selected. I do this alot when I don't have a snappable object nearby and/or the destination is off-grid. Raymond
  15. Dave, If my last post is to be considered true, my days are longer than they used to be. Sorry for the delay. A clear explanation is difficult to put concisely in words, at least for me. The effects of AngleVar and NoAngleVar carry forward through a script in a top down manner, regardless of procedure boundaries. They control the compiler, not the execution of a script, by telling the compiler what format of angle data to expect after an AngleVar/NoAngleVar was encountered, and they remain in effect until the next NoAngleVar/AngleVar statement is encountered. If you switch modes, you'll need to put AngleVar/NoAngleVar into each procedure that has angle values, to direct the compiler correctly. Think of the commands as reading Angle-Variables-Only (AngleVar) and No-Angle-Variables-If-It-Can-Be-Seen-As-A-Compass-Point (NoAngleVar). "#" seems to have two effects. It can indicate that angle data is present OR that literal angular data is present. Some commands can be used in orthogonal and polar modes. The "#" indicates polar. MOVE is such a command. Normally, MOVE is used for X & Y pen displacements, but the following example shows it in the polar form. MyAngle := 40; Angle data is present: Move(1, #MyAngle ); { move pen 1 unit at 40? - works in both modes } Literal angle data is present: Move(1, #NE); { move pen 1 unit to the NE or 45? - works in NoAngleVar only } Use AngleVar and NoAngleVar to clear up any confusion that may result from variables that start with the letters (N, S, E or W). NoAngleVar is the default. When NoAngleVar is in effect, VS will try to interpret the expression "#AngleData" as a literal (not a variable), and "AngleData" as a variable. Eight compass points are recognized. When a variable that starts with (E, NE, N, NW, W, SW, S, SE) is preceded by "#", it will be seen as (0, 45, 90, 135,180, 225, 270, 315) degrees respectively, even if it was not intended to be a literal (this is an advertised compiler feature). So, the variable ?#NeverOnTuesday? will be seen as #NE and 45? will be used, not "NeverOnTuesday?s" stored value. The name ?OnlyOnTuesday? can be used as a variable when NoAngleVar is in effect since the compiler can?t force ?OnlyOnTuesday? to a compass point, but ?#OnlyOnTuesday? may generate a compiler error with some commands since it cannot be interpreted, or misinterpreted as it were, as a literal. On the other hand, AngleVar tells the compiler to act like most compilers do and treat variable names as, well, ? variables. The use of "#" in this mode is used to indicate that polar data is being specified, as shown in the example above. In earlier versions of the program "#" was accepted wherever angle data was required. Now, there are some exceptions. When in doubt, put it in, and if the compiler kicks an error, take it out. Not very scientific, but compiling is quick and the compiler knows what it likes. HTH, Raymond Scripting since MC+2.0 [ 07-30-2004, 03:06 AM: Message edited by: MullinRJ ]
  16. Pressing ENTER used to close the VS-Editor by accepting changes (OK Buton), now it does nothing. You now have to mouse-click one of the buttons to close the window. Please reinstate that key's function. It would also be nice if ESC closed the window without accepting changes (Cancel Button). Thank you, Raymond User since MC+2/1990
  17. Dave, I can explain it, but it will take some time to write it up. Although I am a latecomer to both the List and the Board (I wish I knew about them sooner), I believe the list was around long before the board and the list users like the email format. There is good help in both places, but if you want to learn all you can, stay tuned to both. I'll get back to your questions later today. Raymond
  18. Hi Dave, AngleVar & NoAngleVar are essentially compiler directives. They indicate to the VS compiler the format that angle data will be encountered in subsequent code, until changed. The short answer is - if you never use angle bearings for angle data (i.e., N, SE, WNW, etc.), use AngleVar. One caveat to keep in mind, if you use AngleVar at the beginning of your main program, it's effect will not carry forward at runtime into user defined procedures. Use AngleVar at the beginning of any procedure that uses angle data. After reading the page you cited, I too am confused. I remember the definitions of AngleVar and NoAngleVar as being the other way around. The online manual (and all the HTML manuals I've downloaded all the way back to VW8.0) states that quote: ... AngleVar will cause VectorScript to treat language symbols which can be interpreted as direction angles (e.g. N,S,NW,SE) as angles, rather than as variables.Here's the definition of AngleVar I remember (and still abide by today). I cite the MiniCad+ 2.0 MiniPascal Language Manual (ppg. Macro 3L.139?140) ? quote: ? if the user calls procedure AngleVar, this notifies the computer that variables will be used for angle values. Conversely, the procedure NoAngleVar informs the computer that no variables will be used for angle values and that any letters encountered should be treated as bearings. ?I use AngleVar in most of my VS programs and it works consistently as described by the older definition. If this is still confusing, write back. I'll be glad to work through any issues with you. HTH, Raymond
  19. Sorry Chrissy, I do not know of a way to assign colors to the palette via VS. This appears to be another area where VS has a GET function without a SET function. I only quickly checked the v10.5 reference, perhaps it I did not see it or it has changed in v11. Maybe someone else knows better than I. Best of luck. Raymond
  20. Hi Chrissy, You are right in assuming that VW snaps assigned colors to the nearest color palette value. Try adding the following 2 lines to the end of your program to see what value is actually assigned. GetFillBack(hndObject, lngRed, lngGreen, lngBlue); Message(lngRed, ' ', lngGreen, ' ', lngBlue); Then you can take those values (/256) and plug them back into RealBasic to see how well they match. It is also possible to add colors to a color palette. You might explore adding the chosen color from RealBasic into the VW color palette and then applying it. I don't know how well they will match, but it's worth a try. Raymond
  21. One other consideration you will have to make: You will need a copy of VW8 or VW9 to be able to convert his MC6 files to VW11. This assumes that NNA still doesn't have a translator for the older versions yet. VW typically reads back 3 versions, so VW11 should be able to open VW8 files. I believe the sales department will help you bridge the gap. Raymond
  22. Hi Peter, There are different ways to work inside groups, but I tried the following code to see what would happen, and you can enter a group and do what you want the way you suggest. DoMenuTextByName('Group Navigation Chunk', 1); SelectAll; I created a group, entered it, deselected everything, then exited. With only the group selected I ran the above code. The objects inside the group are selected. On exiting the group, no other objects beside the group are selected. Raymond
  23. And UNDO only resets the unlocked line. Raymond Mac OS 10.2.8 / VW 10.5.0
  24. Hi Tom, Thanks for your response. I have been GOOGLE-ing a lot and reading everything I can find on cubic splines. Yes, finding the boundary conditions is a good part of the problem I am trying to solve. In the case where the Polyline points are of types Bezier, Arc or Corner, all the end points and control points for a given Bezier segment of the curve can be ascertained by knowing three points; the Polyline point in question, the Polyline point preceding it and the Polyline point following it. In the case where those three points are all of type Cubic Vertex, none of the control or end points are obvious, they are all virtual, meaning they must be calculated from the data at hand. I am hoping that NNA will provide a short paper on how they determine the end & control points used to implement the parametric equations for a Bezier (Cubic Spline) curve segment. How many polyline points before and after a cubic vertex are used to calculate the control points for each segment? When Cubic polyline points are adjusted with the 2D reshape tool, virtual points appear on screen with associated tangent lines. These are the points I am trying to calculate. From my rough drafting, it appears that the virtual point would be equivalent to a Bezier Vertex point and the midpoints between this virtual point and preceding and following ones would correspond to the end points P0 & P3 in the Bezier curve segment model. These three points would be enough for me to calculate the curve between them. I just need a little more help in seeing what I am missing. Raymond
  25. Hi Katie, I am trying to emulate the curves that are generated on screen using the data points that compose a polyline. The points are the ones returned with GetPolylineVertex(). I can replicate Polyline curve segments when the Polyline points are Corner Vertices, Bezier Vertices, Arc Vertices, and Cubic Vertices (if the preceding and following points are Corner points). I am having trouble figuring out how you implement a Polyline curve when it is constructed of a series of Cubic Vertices. Any technical notes you have on its mathematical implementation would be appreciated. Thank you, Raymond
×
×
  • Create New...