Jump to content

MullinRJ

Member
  • Posts

    2,007
  • Joined

  • Last visited

Posts posted by MullinRJ

  1. You're welcome, Ion. Had you looked in the VS Appendix you still wouldn't have found it, unless you looked at one of the "special" appendices maintained offline. Thank VCOR for publishing a more "special" list.

    Raymond

  2. Ion,

    ???Try using:

    SetPrefReal(68, newXvalueOfPageCenter);

    SetPrefReal(69, newYvalueOfPageCenter);

    ???I've not used them before, but in a very cursory trial it appears you might really want to use:

    SetPrefReal(69, -YvalueOfPageCenter);

    ???Not sure why, but it appears positive values of X move the page right (as expected) but positive values of Y move it down. This may be a throwback to screen coordinates where (0, 0) is in the upper left corner and all values on the screen are positive (just guessing).

    ???Be careful if the page and the user origin were both moved. I think Pref68 & Pref69 reference absolute coordiantes, not User coordinates. Some subtractions may be required.

    Good luck,

    Raymond

  3. Hi Charles,

    ???I've never had any trouble with Str2Num(). Have you verified that your string has only numeric values in it when you try to convert it? Leading or trailing blanks seem to be OK, but any other alpha character will make it fail.

    ???I use ValidNumStr() to test values before proceeding with dialog entries. It has Str2Num built in. If it fails, I loop back to the dialog and make the user try again or cancel. A message window with a prompt, hint or result is always nice, and it gives you a chance to display the string that fails without having to enter debug mode.

    if not ValidNumStr(Str, XDiam) then RepeatSecondGrade

    else ContinueOn_or_DoGoodStuffHere;

    Raymond

  4. If the view is NOT Top/Plan, then the OIP does not show info for Group objects.

    If this is important to the way you work, my Reshaper utility will show size and position info for Group objects in any view, plus a whole lot more.

    Raymond

  5. Loci, IMO, should never show any line weight above the minimum needed to make them visible on the screen. In all versions before 12, Loci showed thin lines at all zoom levels. In v12, Loci begin to show a line weight at zoom levels around ~3000%, above which they appear as large blobs - fuzzy and indistinct. Only turning off the Zoom Line Thickness preference makes them appear as they should.

    Though this may not be considered a bug, I feel it was an ineffectual change to the program. I hope to see the Locus returned to its previous appearance someday. Is there any improvement in VW2008?

    Raymond

  6. Maybe you don't watch many inexperienced users operating VectorWorks?
    I try not to, but I don't believe changing software to accommodate the inept (even if it is transitory) is a sound reason for change. It seems other efforts should be employed to address such a problem. What's wrong with training?

    The only major advantage I can see is that it's the status quo and I really doubt anyone, including yourself, would be arguing for floating windows if the status quo was a unified interface.
    It isn't, so we'll never know.

    For whatever reason, I happen to like what exists. It works exceptionally well for me and in my opinion has distinct advantages over a unified window interface, which I consider to be clunky at the very least. I often use multiple applications simultaneously, and desire to have multiple windows open and visible, selectable with just a click. This may be old fashioned, but very powerful for the way I work. So cast my wish to negate your wish. Still, nothing personal.

  7. Make a 32x32 pixel icon. Leave the top and bottom 7 rows of pixels white. Leave the left and right 4 columns of pixels white. The remaining pixels in the center make up the visible 18 rows by 24 columns. The unused pixels don't need to be white. Any color can be used, but they won't be seen.

    HTH,

    Raymond

  8. I'm with Pat, and the Status Quo, and the Silent Majority, and the Peanut Gallery. Please don't mess up a good thing. Change for the sake of change is painful, at best, and at worst, mind numbing. Palettes need not clutter up the landscape. Most of mine are off most of the time and the screen is filled with a very large drawing area. Beauty to the eye of this beholder. Wish for the sky, but I for one wish your wish is never granted. Nothing personal. ;-)

    Raymond

  9. You can place functions in an $Include file without wrapping them in a procedure. I do it extensively in my Reshaper program - hundreds of them. Try placing a blank line at the end of each included file. A little white space at the end of each makes sure the compiler won't join two keywords when it reassembles your code.

    Raymond

  10. Gerard,

    ???Your replies are poignant, especially the "Pirates..." reference, but I fear your words fall distantly short of affecting their intended target. However, they are enjoyed by all others.

    ???Petri's ego has centered itself in a perfectly mirrored sphere, a place where he sees only himself while all others are conveniently reflected away - a white hole, analogous to the rectum of a cosmic black hole - a singularity where emanates but none can possibly enter. The problem isn't that it is forbidden to enter, but rather that it's completely full of itself. It has been asked, "If a Petrisphere emits crap, would that event not make room to receive external input?" The answer is, "No, due to the instantaneous creation of fecal matter from the entity within the Petrisphere." This insures that the Law of Conservation of Elliptical Thinking is never violated. Add to that, the radius of the perfectly reflective Petrisphere Event-Horizon is constantly maintained, which expands to precisely contain all sepsis and will do so as long as there is a positive flow of self absorbing admiration within. The net effect is a total repulsion of the universe around it.

    ???At one time it was theorized that the radius of a Petrisphere is monotonically increasing, that is, it is either static or growing but never shrinking, perfectly entrapping the ego within; but that theory has recently been challenged by some very abstruse individuals who hypothesize that under the rarest of conditions, the radius of a Petrisphere may indeed appear to shrink, and possibly disappear. It would be necessary for an ego trapped within a Petrisphere to self-consume, which would entail the total ingestion of the surrounding cesspool contained within the Petrisphere, including the ego itself. Since no input from outside a Petrisphere can affect the contents within, the idea of self consumption must originate from within and it is in realizing this extremely rare sequences of events that the authors of the Shrinking Petrisphere Hypothesis acknowledge the odds of this happening within the expected lifetime of the known universe are essentially zero.

    ???It is because of my understanding of Petrisphere mechanics that I have refrained from hurling anything at it. However I do believe many have taken pleasure in witnessing how anything and everything is perfectly deflected by the Petrisphere at its event-horizon. I have also noted that quite a few have continued their assault of the Petrisphere in such a way that it appears to give them pleasure. I fear that if this cycle of pleasure seeking stimulus is not abated, we may see a new form of addiction evolve, Petrisphere Poking.

    ???A Petrisphere Poker should be easily identified by his or her inability to look away from a Petrisphere whenever a piece of flotsam is emitted. Like moths to a flame, a Petrisphere Poker will habitually return and respond to such emanations, no matter how foul they be. I can only imagine a Petrisphere Poker receives great pleasure in seeing how his or her responses are reflected and/or distorted. Though I don't currently advocate discouraging anyone from staring into a Petrisphere, I think I may recommend at some not-too-future date that action be taken to avoid the inevitable negative consequences that will undoubtedly plague anyone who entertains themselves by persistent Petrisphere Poking. Until such time...

    Ain't life grand?

    Raymond

  11. Oh, and permissions. They are one of the dumbest things about OSX. Its the Mac's dip switch. Apple should internalize this process because nobody normal understands it, and it's hard to see the positive effects.

    I can't claim to understand all the ins and outs of disk permissions, but I have never had one bite my posterior, and when running Disk Utility have only seen one or two permissions out of whack at any one time on a "pivotally important" color profile file, or some such.

    It's always amazed me how many people have problems with such things. That said, I may be using my Mac in a way that minimizes this problem. My machine runs 24/7 and more often than not I am using it after midnight. I have heard that OSX runs maintenance operations in the wee hours, so if the machine is off from midnight to dawn (or even asleep), entropy creeps in, thus requiring manual intervention.

    Perhaps someone more knowledgeable in the underpinnings of OSX would comment and shed some light here.

    Raymond

    G4 & macMini - OSX 10.4.10

  12. ???The Script Editor is limited to 32K characters, not lines. The Plug-in Editor does not have that limit. Using $Includes in the Script Editor will not get around the 32K limit, since all the included files are copied into memory before your code is compiled and run. If it exceeds 32K, it will kick an error.

    ???Large scripts can be developed easily using the PlugIn Editor. If you place an $Include statement as the first an only line in the PlugIn Script section pointing to a text file that contains your code, you can make changes to the text file, save it and run the script again without opening the PlugIn Editor. You will also need to enable the "Don't Cache Plug-in Scripts" VW Preference (407) to force VW to recompile the script each time it is run. Use the menu Tools>Scripts>VS Compiler Mode to toggle this setting.

    ???It is also possible to use many $Include statements and nest them several layers deep. My Reshaper 12 program is 625K and uses 46 $Includes, 3 levels deep. I've not yet had problems working this way.

    Good luck,

    Raymond

  13. Hi Jeff,

    ???Try the following "untested" code snippet to step inside and count your embedded symbols. You can use an outer WHILE loop to step through the selected objects, or give this snippet a function name and use ForEachObjectInLayer(), pick your poison.

    HTH,

    Raymond

    { for each selected symbol instance pointed to by SymHnd, step inside and look around }

    H := FInSymDef(GetObject(GetSymName(SymHnd)));

    while (H<>nil) do begin

    ???if (GetType(H)=15) & (GetSymName(H)=TargetSymName) then

    ?????? Cnt := Cnt + 1;

    ???H := NextObj(H);

    end;

  14. Try:??SetPrefReal(70, 2);??????{ = 50% }

    or:????SetPrefReal(70, 0.5); ??{ = 200% }

    One scales down, the other up. It's a 1/x thing so guessing may be required. One of them should work.

    Pref 70 is the "Page Scaling Factor ". It changes the elusive printing scale factor found in:

    Page Setup > Printer Setup... (button) > Settings: VectorWorks (popup menu) > Scaling: xxx %

    I've done it manually, but never by script (until tonight). Don't forget to set it back to 1 when you're done or you'll swear something's broken the next time you try to print. I don't know if it is document specific or works application wide. I assume the latter, but don't get me to lying. I also don't know if it resets to 1 (100%) when VW is relaunched. You'll have to play with it. Write back when you figure it out.

    Raymond

  15. Your function declarations are as follows:

    FUNCTION LibHasIDLabel(theObj: HANDLE; VAR theRecordName, theIDLabel: DYNARRAY[] OF CHAR): BOOLEAN;

    FUNCTION CopyOver(theDestPIO: HANDLE): BOOLEAN;

    And your calling line:

    IF (LibHasIDLabel(theDestPIO, destPIORecName, destPIOIDLabel)) AND (LibHasIDLabel(srcPIO, srcPIORecName, srcPIOIDLabel)) THEN...

    When your function LibHasIDLabel completes, it returns a pointer to variable space that was local to LibHasIDLabel; space that disappears the moment you leave LibHasIDLabel. The equivalent space has not been reserved in CopyOver since you never allocated it, so there's no place for the answers to reside when you return. You must ALLOCATE space for your DynArrays before they can be used.

    Try:

    ChrCnt := 94; { or whatever size your array of Chars needs to be. }

    ALLOCATE destPIORecName[1..ChrCnt];

    ALLOCATE destPIOIDLabel[1..ChrCnt];

    ALLOCATE srcPIORecName[1..ChrCnt];

    ALLOCATE srcPIOIDLabel[1..ChrCnt];

    IF (LibHasIDLabel(theDestPIO, destPIORecName, destPIOIDLabel)) AND (LibHasIDLabel(srcPIO, srcPIORecName, srcPIOIDLabel)) THEN...

    Now, when LibHasIDLabel returns, your data has something to come home to. Of course, ChrCnt can have a different value for each variable, if your needs require it.

    HTH,

    Raymond

×
×
  • Create New...