Jump to content

Stefan Bender

  • Content Count

  • Joined

  • Last visited

Community Reputation

7 Neutral

About Stefan Bender

  • Rank

Personal Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks Joshua, that seems to be a good approach. It also activates all other symbols/PIO within the wall, but maybe I can deselect the ones I don't need afterwards.
  2. Dear developers, our window and door tools create PIOs that are inserted into a wall. The user clicks on a position in the drawing and the PIO is created there, if the position is over a wall, the PIO is inserted into that wall (i.e., the wall gets a symbol break and the PIO is the break's "symbol"). So far, so good. But unfortunately it does not seem to be possible to select the inserted PIO visibly. I called SelectObject of course, but no selection handles to be seen (the wall itself is NOT selected). I checked at the very end of my tool's HandleComplete() function that IsSelected() returns true for the PIO, but no selection handles are visible and the OIP remains blank. Is there a special trick to select PIOs in wall breaks? Or is it a bug in ISDK::SelectObject? Thanks for any help, Stefan Bender
  3. You might try calling VWResourceList::BuildList(short objectType, IFileIdentifier* fileID);
  4. I just got a mail from Vlado who suggested changing some project setting (see attachment). I'm rebuilding the plug-ins and see if it works.
  5. Thanks, but this function just returns a handle to a group. It doesn't tell you if the group was created by the user or by the PIO.
  6. Hi all, how can I find out if an object style has user-provided 2D components or not? Or more precisely, if a given 2D component (top, front, back...) is user-provided or not? I can't seem to find an SDK function for that? Thanks for a short note, Stefan Bender
  7. Another related issue: After the upgrade to XCode 11 we keep getting build errors in seemingly random plug-ins that are caused by codesigning. The error message says it's about resource forks or finder info. Some site in the Internet said >>According to Apple: >>Note that browsing files within a bundle with Finder’s Show Package Contents command can cause Finder info to be added to those files. Obviously, we need to do such browsing very often, for instance when we edit .vwstrings or .vs files. So what can be done to make sure that this codesigning stuff doesn't interfere with the builds? Can we try switching codesigning off? Or try removing the resource forks &c automatically before each build? If we try that, we would need to assign write permissions to the files in the bundle which could interfere with Perforce. Thanks for any help, Stefan Bender
  8. I think it would be a very bad and dangerous idea to use the symbol's bounding box or other symbol data for calculations or anything else but mere display. Overriding (or even worse, changing) data the user entered could create complications. The symbol is just meant for optical purposes.
  9. IIrc we are using the old function (without N) in our code. I think it works fine for polylines, rectangles and arcs. I don't know if we are passing other object types. I'm not sure if it is possible to create polygons with less than 3 vertices.
  10. Maybe you can check if h == tempPoly to avoid these crashes.
  11. Maybe there are different local standards how to display the sliding direction. IIrc we also use arrows in the German/Swiss sliding door PIO, but maybe we should do some research and provide all options that are common in targeted countries.
  12. IN the constructor of one of our classes, we query for a VCOM interface: Boolean succ = VCOM_SUCCEEDED( ::GS_VWQueryInterface( VectorWorks::EnergyAnalysis::IID_EnergyBuildingElementWinDoorEx, (IVWUnknown**) & m_energy_2021 ) ); As requested in the SDK documentation, we release that interface in the destructor of the class: if (m_energy_2021) { m_energy_2021->Release(); // m_energy_2021 = nullptr; } Before releasing, the refcount (m_energy2021->fPtr) is 1, after releasing it is 0 which looks OK. But after the end of the destructor, it seems that the VCOM destructor is called again, tries to release again and gives a debug warning saying refcount <0. Is this OK? Should I release the interface by myself or wait for the automatic destructor? SDK doc says I should release, but looking at the source code in various SDK plug-ins I get a mixed feeling, in some routines the interface is released, in others it is not. What is the correct workflow? If I am supposed to release the interface by myself, why do I get the debug warning? Thanks for any help, Stefan Bender
  13. I never used this function, but maybe the dialog is not yet displayed when you call the function? Does it fail on Mac and Windows or just on one platform? Does the control with the given ID actually exist and is it a static text control? Which RGB values are you passing? How did you initialize the CRGBColor? Check if your color has a valid color ref and check the RGB values.
  14. In one of our plug-ins (search and replace) we have to enter and leave symbol edit mode several times while a dialog is running. I.e., one user action enters symbol edit mode, another one should leave it. We are using ISDK->DoMenuName("Group Navigation Chunk",1) to enter symbol edit mode (works) and ISDK->DoMenuName("Group Navigation Chunk",2) to exit, but that does not work. Even after the call, you still see the orange "Exit Symbol" rectangle at the right top corner of the screen. Only after you quit the entire dialog, the orange recangle disappears. Is this a bug in VW, maybe a redraw issue? Or is there another way to exit symbol edit mode and make the orange rectangle disappear? Thanks for any help, Stefan Bender


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

  • Create New...