willofmaine

@Ned Flanders, Thank you for your response and all the info! In your first paragraph when you say "Offline-only" I assume you mean "Online-only"? I don't see an "Offline-only" option, and in any case it seems offline-only would defeat the purpose of Dropbox... I like to think none of us is saving our Working files to Dropbox. I haven't seen any VWXW files in Dropbox, though I realize they could be saved in one's own Dropbox folder that isn't shared. I do know that the team members apparently most closely associated with the disappearing Master file did send some Working files via Google Drive, so I will definitely pursue that as a possible explanation. Ideally, all users would be on the most current version of VW. We're all on 2023; I'll check to confirm that we're all on SP3. If this isn't possible, ensure all Project Sharing users are on the same VW version and the exact same Service Pack Ensure all users are on the same version of Dropbox (EXACTLY the same) - right down to the very last version decimal place! I'm pretty sure we're not. I'm hesitant to update because of the bad things I'm reading about Dropbox, but I guess we all have to accept downgrades to software such as the Mac operating system and, now, Dropbox in order to keep moving "ahead..." Because "Dropbox for macOS" suggests to me that there are different versions for Mac vs. PC, would we even be able to match versions right down to the last decimal place?... Save and Commit at predetermined times so that users aren't synching to the VWXP at the same time Haven't previously had any trouble with this; the system seems pretty good at "taking turns." Proactively clear the projects sharing metadata Good idea... we wait until we get the warning, then impatient people inadvertently jump the gun... Proactively recreate the VWXP from time-to-time Okay Inform the entire VW Project Sharing team before recreating the VWXP file Absolutely Don't Save and Commit and close your laptop lid. Ensure that both the VW synch and Dropbox synch have finished before putting your computer to sleep and having a Friday beer. Noted; I don't have a laptop, but others do. Again, Thank You!!

I'm working with a small team spread across the World, using a combination of Macs and PCs, with a Project Sharing ("Master") file in Dropbox (I'm pretty sure this is not a LAN situation...). A couple of days ago I updated one of our projects to VW 2023 and re-created the Master file. I then made some changes with my new Working file, and all was fine. A few hours later, my Working file couldn't find the Master... and neither could I, when I looked in Dropbox. It simply wasn't there, and was nowhere else to be found. So we spent many hours trying to figure it out and hopefully preserve whatever work anyone might have done. Ultimately we created a new Master from a Working file. Then, the original Master, somewhere along the way and somehow, reappeared (it may have been restored from Dropbox? (I'm not sure)). In any case, we have no idea why or how this could have happened, and our faith in the Master file is no longer. In the meantime, I'm not reading good things about Dropbox (which, for me, up until a couple of days ago had been a solid 5-star component of my workflow...). So... with no real understanding of the crime, Dropbox is our prime suspect. Any thoughts greatly appreciated!! 1. Both MacOS and Windows 2. Dropbox v166.4.2920; another Mac user has upgraded; no idea for the other computers 3. Dropbox is located in my main User folder 4. On my computer, new files are set to default to "Available offline." I've advised the rest of the team to make sure that the Master file and folders containing it on their computers are set to be available offline VWIS237

Just wasted 15 minutes trying to figure out why I couldn't see objects on other design layers and why "Unified View" is grayed out in VW 2022. So this was very helpful (but I think it's Document Preferences, not VW Preferences...). And I guess "Unified View" (under "View") is grayed out because it's just part of my migrated workspace...

VW 2023, SP3: "Marionette network node connections are preserved when importing, copying, and pasting." Does that mean what I think it means? I like to think it means that Marionette wires will now be far more tenacious at staying present and connected than they have been for at least the past seven years. With a little testing, and except for one instance where all the wires completely disappeared, so far, Marionette may show some promise with SP3, both with project sharing and otherwise. A complex Marionette survived a master project file, duplications and edits in a working file many states away, commitment to the project file, and further use in my working file here. Not only that, where in VW 2022 this particular Marionette takes 18 seconds to "reset" after being duplicated and changed, in VW 2023 (SP3) it takes only a fraction of a second(!). And maybe, hopefully, Marionette Object Styles will be a viable replacement for network symbols, which I abandoned due to their apparent endless issues (oddly, Marionette Object "Styles" seem to function much more like symbols than they do the styles for other plug-in objects...). So given Marionette's long history of appearing to work one day and failing the next, I'm nowhere near cautiously optimistic, but at least I'm desperately hopeful...

Does anyone use Marionette with Project Sharing?... ... ...

I can't get Marionette objects to work with Project Sharing. When another User goes to edit the Marionette, it just disappears (though the Select Similar tool will still find it). It looks like the wires get confused, maybe not unlike as in this post: https://forum.vectorworks.net/index.php?/topic/57586-marionette-and-project-sharing-issues/#comment-287920 Screenshot 06, attached, shows the failed network (in this case a symbol). Most of the wires have simply disappeared, one has gone entirely rogue, and a bunch connect to the one node of the "Scale Donut" wrapper, which wrapper has lost its other inputs. So I created a brand new, blank Vectorworks file ("01-Simple Marionette.vwx", attached) with just a simple, rectangular extrude Marionette. In that file, the upper row of objects share the same network symbol; the lower one does not use a network symbol. I put a copy of the file in Dropbox and saved it as a Project Sharing file. I then created a Working File from that and, at least based on limited testing, the Marionettes all worked as expected (drag copying them and editing them presented no issues). I then switched my computer to a different User and there created another Working File. The upper row of Marionettes seemed to work okay, but after I duplicated and tried to edit the lower Marionette, it disappeared. Attached is a screenshot (Screenshot 07) of the network for the original lower Marionette, where at least one wire has made for the hills. After switching back and forth between Users a couple of times and making edits, the Marionettes that had previously disappeared reappeared in the Working File on my main User account. Also attached is the latest Working File, "05-Working File-Refreshed from Successful Twin.vwxw". (In my main project file, the issues first encountered in the other User account were transmitted to the Working File on my main User account, and the "failed" Marionettes did not reappear...). Any thoughts greatly appreciated. Thanks! VWIS236 01-Simple Marionette.vwx 05-Working File-Refreshed from Successful Twin.vwxw

It seems like Marionette doesn't work with Project Sharing. Or am I missing something? I created a test file with some Marionette objects. I put it in Dropbox and saved it as a Project Sharing file. I opened a Working File, and everything worked as expected. I signed out of my main user account and went to my evil twin user account, where I created another Working File. There, when I tried to modify a Marionette, it simply disappeared. When I edited the script for another Marionette, its wires (in a network symbol) were disconnected or, mostly, just non-existent. With the Select Similar tool, I determined that the invisible Marionettes still had some kind of presence. When I returned to my main user account and refreshed that Working File, the Marionettes seem to work as expected, but the invisible ones still have their presence.

Yes, thanks, that explains it. But begs the question... why can't "basic" tools be assigned to a class? Maybe a Wish List item for another day... Thanks!

Hi @Boh and @Pat Stanford, thanks for the responses. "SetTool" worked to make the Line tool remain active, but then the line wasn't drawn in the correct class. When I removed the Push & Pop Attrs, it was drawn in the correct class but, also, its class was made active. I was hoping it would put the line in the correct class without changing the active class, as it does for just one instance. I couldn't see how the script knew what tool it was activating, until I changed the (-201) to a (-202) and got an arc. I'm guessing there isn't a similar code for the Redline Tool, because as Boh says, it seems like some plug-in object are (inexplicably?) beyond the reach of the custom tool command. I guess I need to limit my use of the Redline Tool to its strict capabilities...

So I think I got it to work, for a dashed line. The tool needs to be active, and the line in question selected, when the "Custom Tool/Attribute..." command is run. Oddly, activating the script only activates the Line Tool for the creation of one single line, after which it's necessary to run the script again. But when I use the same approach to create a script for the Redline Tool, the "Tool" option of the "Custom Tool/Attribute..." command is grayed out. Why???

Huh? I want two versions of the Redline Object created by the Redline Tool: one that is automatically placed in a design-layer-only class, and one that is placed in a sheet-layer-only class (if they're all only in the Notes-Redlines class, sheet layer viewports get cluttered with design layer redline objects). Sadly, things like callouts, revision clouds, and, evidently, redline objects are all super useless when saved as Symbols for future use (I've tried all kinds of combinations of convert-to-group vs. not, world scale vs. page scale (especially with callouts), all to no avail.) I now see that, in any case, saving those types of objects as Symbols doesn't activate their tools; it just places flawed instances of them in the drawing. So... I thought I'd try the Custom Tool/Attribute command to create a script that would place a Redline Object with the desired settings in the desired class. VW Help says "scripts record the current attribute and file settings of a selected object in a script format for later use." How? After I create a Redline Object, as I want it and in the class I want, I follow the VW Help steps to create a script. But when I double-click on the script to run it, at most it will just change the active class (which I don't want). Otherwise, nothing seems to happen; the Redline Tool isn't activated. What am I missing?? @Pat Stanford any thoughts? Thanks!

Nope, you didn't misunderstand; I've never really used the Stair tool and I just wasn't getting it right. The labeling was secondary. @line-weight Yes, I always spell out "down." But I gotta say, I like the standard of arrows always pointing up and not having to label the arrows. So now I'm thinking a general note on drawings that simply establishes that convention.

@E|FA It helped a lot, actually. I saw that you had markers at the breaks, the lack of which I was just starting to realize was a problem. Then I saw that you had "Show markers at break" selected... who would've guessed? So that headed me in the right direction, and now I've got it through my thick skull that there are markers available at both ends of the walkline... and I'd recently set the attributes to use my "Stair Arrow" class... ...which has the same arrow markers for both ends. So it really didn't matter if I was pointing up or down... Vectorworks was obligingly giving me the same arrow either way. Guess I can't blame this one on Vectorworks... Thanks! @zoomer I honestly don't know if there's a standard here, or what it might be! I've always just labeled my arrows "Up" or "Down" to be clear. Thanks for your response.

So... am I missing something? Or does no one actually use the stair tool? (I avoid it, but a client uses it). Or do we all just do Escher stairs because that's what our software dictates? It looks like this was an issue back in the year 2008: https://forum.vectorworks.net/index.php?/topic/21611-stair-arrow-direction-convention/#comment-100888 And even then, it had been an issue for several years. How does it take 14+ years to not fix this?... If ever the stair arrow is fixed, it would be helpful to have the option of "Up" and "Down" labels. Arrows are meaningless unless either they're labeled or there's a convention (such as stair arrows always point up, which appears to be the case for many parts of the world (probably those parts of the world where they don't measure with a combination of sixteenths, twelfths, thirds, and 5,280ths... ... ...)).

How do I actually get the stair arrow to point in the correct direction? For "Break, Dashed Above," whether I select "Pointing up" or "Pointing down," it points down. For "Above Break Only," whether I select "Pointing up" or "Pointing down," it points up. (VW2022, SP5) VWIS235