Folks:
Attached is a rough draft of a new shape I'm working on, an articulated line, and I need some help.
The way It works is that you can add or remove additional line segments, with the location of each vertex managed by moving a control point. That was fairly easy to accomplish, but the place it got difficult is where I added moveable arrowheads to the first line segment. My question is: How can I add a similar pair of moveable arrowheads to the second and third line segments? I've wasted far too much time trying to get the beast to work, but to no avail. Any suggestions?
Thanks in advance,
- Ken
Oh, I see. I thought you were talking about a highly educated, proper line. Just kidding.
Not sure this will do what you want, but here's a variation. The arrowheads remain at the end of each segment. I only did two segments. Note, geometry1 defines the beginning and end points, and all segments would fit within these limits. Geometry1 is not visible. Best I could come up with at this late hour.
Cheers.
Wapperdude
Doh!. Never mind. You can control the appearance of the arrowheads by turning the fill on or off. So, the construct for the other line segments just needs to be similar to the first. You end up with one section that has full length line with no arrowheads, and then a 2nd line with arrowheads that overlays the first. Gives the illusion of moving arrowheads. That was my quick and dirty after looking at what you did.
Here's updated file to give you the idea. If you have newer version of Visio, I think it's not too difficult to make the arrowhead control points stay on the lines. Otherwise, I'll leave the math and gory details to you.
Anyway, HTH
Wapperdude
Mr. Dude:
Thanks for taking the time to play around with the inarticulate articulated line.
Quote
I think it's not too difficult to make the arrowhead control points stay on the lines.
LOL! That is
precisely the issue I've been grappling with!
Some brief background: I've been using the simple, single-segment version of that line for years, adjusting the arrowheads as artistically necessary. There are times where I need to connect multiple single-segment lines into one longer, articulated line—I've found they are much better behaved than Visio's native self-routing lines—but connecting multiple lines has its own foibles (accidentally disconnecting, losing right angles, issues with innie/outtie connection points, etc.), so laziness dictated that I try to build a better-behaved, multi-segment version of my classic single-segment arrowed line. Which brings us to the issue at hand.
As I mentioned, supporting multiple segments is no big deal; the issue is keeping those pesky arrowheads on top of their line on the additional segments. Obviously it has to begin with a row in the Controls section so that you can move the arrowheads to suit, but how do you limit things to keeping their endpoints on the host line segment? I tried several approaches, but it seems a true solution would be contradictory. You can't GUARD the X and Y on the Controls; that defeats the purpose of the control. Nor can you use GUARD on the GEOMETRY section because the control points will still be free to go where they may. BOUND was handy to keep the arrowheads from exceeding the X-endpoints of the host line segment, but it's constraining the control point itself that's stumping me.
Having the arrowheads constrained to the line is important to me, because if it does not behave itself automatically, then I have to go in there and manually align things. That's a cure worse than the disease.
One option I expected to hear was to use a group, but that has even more problems. You can hide the group-ness easily enough, but if you move the wrong line segment, the connection is broken. GUARDing the connection does not stop that if you move the unGUARDed side.
So I'm stumped. And I do not want a VBA solution. That'd be cheating. ;- )
- Ken
Briefly thought about grouping, and just as quickly dismissed it. My initial reaction says this can be done in shapesheet alone. Seems like it's close.
I forgot which version of Visio you have. With newer versions, I think that point along a curve, or whatever it's called, would do the necessary positional constraints. Then, add the bound fcn to keep each narrowband within the limits of its line segment.
Alas, I only have V2007, so cannot pursue that thinking any further. If you're still old school like me, then I'll have a go at the formulas. I may actually have that solved...need to rummage about a bit.
2 cents to consider
1) you can use loctoloc to lock the arrow the end of the line. something like
guard(loctoloc(pnt(<line x coord>,<line y coord>),<line ref point - width or similar>,<arrow ref point - idth or similar>)
no groups needed
2) as in June's stuff, his primary and shadow lines track to a control point of the group. Where ever you move the
control, June's math makes the appropriate bends to make sure the line end point (or begin point) line up with the control
points
no VBA involved with either...use shape data to assist in usage
Some examples attached
Well, several dead cats later, and just having sooooo much fun, here is an imperfect solution, old school style.
1) Major break-thru was to use the SETATREF family fcns. This "slaved" the arrowhead points to the section control points.
2) The first section from width*0 was easy. The second section, in this case, only two sections, had to handle issues with the section control exceeding the total width. Not an issue if it is less than the zero, as that seems to work favorably.
3) Main issue has to do with the exact, 90 deg cases. These are special cases as they result in divide by 0 scenarios. Obviously, not good.
4) Did not add bound function. This gets really messy as the limits change when either section control is less than 0 width or greater than 1 width.
Well, here's a step. This is a lot of work to be lazy. I kinda like the idea of just a single segment, and gluing segments together as needed. Yeah, they can pull apart, but, at this point, there's no weird cases to handle.
Wapperdude
Wapperdude:
I feel your pain. But between the two of us looking for a solution, the cats never stood a chance. ;- )
Never considered the SETATREF functions—and I mean never. Didn't even know what they did! But that's one of the reasons I hang out here; ya learn new stuff all the time, and here's yet another opportunity.
Seeing how there are still a few cats out there, let me take your fine example and expand it to three or four segments that can be turned on or off at will. Thanks for showing it's possible.
- Ken
I made an attempt to do an in-depth, but understandable exploration of the SETATREF fcns: http://visguy.com/vgforum/index.php?topic=6383.msg26308#msg26308 (http://visguy.com/vgforum/index.php?topic=6383.msg26308#msg26308)
Wapperdude
So I managed to get the arrows married to their respective lines, but not for all permutations. Still, it's solid progress.
The first thing I did was jettison Visio's opinion of what the line is, so I nailed the standard line endpoints on top of each other thereby making the Width, Height, and related cells meaningless. The only lines are the ones I draw, each with their own Geometry. That's what I access instead.
The trick to taming the arrowheads wasn't SETATREF (although I did learn quite a bit about that by playing with Wapperdude's clever examples), but rather a permutation of the calculations he did. I started Pythagorean, but realized all you need to identify where to nail the arrow endpoints is the ratio of how far along you are between the line endpoints. That made it easy, except that it still blows apart under too many circumstances.
Regardless, it is a new approach and it does work (sort of) so I thought I'd post it. I agree that there's an all-shapesheet solution to this somewhere down the line; it's just not there yet.
I also added the right-click actions I'd like to see in the final product: adding and subtracting line segments, and turning arrowheads on and off; trivial stuff in light of the bigger headaches. But at least that part works.
More as it happens, in my copious free time.
- Ken
Interesting concept. Ah, I see what you meant by changing arrowheads. Cool.
I'll look at this some more, see if it's possible to tame some of the wilder behaviors. While this seems like a easy task, as you've discovered, it is fraught with perils.
Quick update: I've spent far too much time on this; "a lot of work to be lazy", as Wapperdude so aptly put it. I'd like to say "close but no cigar", except I'm not close, and there's still no cigar.
I came at it fresh several different times, but all of them depend on the same foundation:
- Nailing the start and end points of the line on the same spot. That makes all lines under my direct control. Still seems like a winning approach.
Using that nailed spot as the starting point of the line. I tried using a control point as the starting point to allow for adjusting the start, but the nailed start/end point ended up in odd locations, especially after moving segments around, and I was unable to hide it. Idea abandoned.
Using the ratio of height to width to nail the arrow line on top of the line segment rather than using Pythagoras. However, I suspect this approach is the cause of wild behavior requiring BOUNDs. Might have to abandon it.
Focusing on getting one line segment to work before adding additional segments. That simplified things immensely because the difficulty is not in creating multiple segments; the problem is taming the arrowheads. Get it to work for one segment, it should be trivial to get it to work for all.
One promising item that simplified things was to use two lines each with a single arrowhead rather than one line with an arrowhead on each end. That eliminated the issue of arrowheads crossing each other and inverting themselves.
That said, attached is the latest effort. I added BOUNDs to keep the arrowheads within the scope of the line and not cross over each other, but other than that it displays all the unruly behaviors of its predecessors. The problem here is fundamental; however, I just don't see it.
Bottom line: I'm ready for a grouped solution. I played around with one, and it's pretty trivial. Segments can be turned on and off, locked against deletion (except with the entire group), connection points GUARDed, and arrowheads easily tamed using the Width shapesheet cell rather than playing around with my own geometries. The only downside is when I link the line (doubleclick or hyperlink): the linking needs to be duplicated across all line segments and to the group itself. Not a big deal; all the segments and group can link via the destination page name stored in the group's user cell. However, it contradicts how I currently handle linking in my macros; I'd need to handle that special case too. More work! But less work, considering the unruly alternative of a single, ungrouped shape that continues to not work.
More as it happens, albeit slowly.
- Ken
RE link links or macros to segments: Could do one of the following
-select child within group then bind the link
-set behavior to show children first (one less click at group level
-at group level, could get into a more complex scenario
- actions to identify the child in play (this would allow a simpler way to have multiple segments use 1 link...
a default perhaps???)
- sets an index in some sort of user.index at group level
- each child watches (DEPENDSON) index to do some sort of SETF(GETREF(<link cell>), <link>) to set link
Well, here's perhaps, 98% of desired. The tough parts are the 2nd and latter segments. This shows solution for 2 segments. There's still the case of vertical 2nd segment not performing as desired, but doesn't go crazy.
HTH
Wapperdude
@Hey Ken
Well, all righty now! I think this is 99.9% of what you were after. Again, this is for just 2 segments. But, I think the pattern is understandable. I've tried to eliminate unnecessary calcs from the shapesheet. The 2nd segment has the number "2" imbedded in the User and Control names. So, for each additional segment, those lines would need to be replicated. I did not do anything to hide the unused segment or its control points. Figured you had that under control.
The trick was the to break for formulas as determined by the slope of the line segments, namely, the 45 deg point. This shifts the arrowhead control to be either dependent upon its Xpos or its Ypos. The dependent calculation then shifts between the Ypos or the Xpos respectively. The ArrowHead will move proportionally to length of its line segment as determined by either the beginning or ending locations.
I've tried to thoroughly test this. There does seem to be some minor calculation round off error right around the 50% arrowhead location on the 2nd line segment. Hence, not 100%.
Enjoy.
Interesting problem.
Wapperdude
Wapperdude:
You cannot imagine how big a smile I had when I saw those arrowheads tracking so nicely with the line segments. But I can bet you can imagine my bewilderment when I looked at the shapesheet! And my degree is in Physics, so you'd think I'd be more comfortable with all the trig. It'll take some doing before I figure it all out, but at least the solution is there. An interesting problem for sure, and it appears you've spent as much time on it as I have. You can get some sleep, now. ;- )
- Ken
The joys of being retired. I don't have a steady job that dictates my time schedule. But having been an engineer, doing circuit design (custom IC's) for 42 years, there's still this need to solve intriguing problems. This one was fascinating because of the sliding arrowheads. Your approach gave me enough "outside the box" perspective to tackle this.
I'm going to repost the solution here, I changed the angular "results" from "Direct" and "Calculated" to "DirX" and "DirY" as being more meaningful. That is, if "DirX", then the AH2 control's Xpos is derived directly from its actual location, and the Ypos is calculated. But, if "DirY" is the result, than the Ypos is derived directly from location and the Xpos is calculated. The results could have been more easily "1" and "0", but that's not very instructive. However, using the Boolean results would have eliminated the "Strsame" function in the AH2 control cells.
Another FYI note: for the Controls.AH2, the direct calculation uses the setatref functions, and the calculated position calls an User.CalcAHD2 formula.
Wapperdude
Wapperdude:
Thought you might like to see the context that drove my need for an arrowed articulated line. Sadly, I have not had the chance to generalize your solution into a reliable packaged product (it still has some interesting behaviors in some corners of its operational envelope), so I'm still building things manually. Someday, perhaps, in my copious free time.
You'll also notice an additional need for the articulated line to branch out into multiple endpoint lines. But once the basic articulated line is tamed, it should be trivial to expand its functionality to fan out the ending segments.
Another item that calls for a solution are the barrels you see in the sanitized JPEG. When I change the height or width of the entire barrel, the height of the not-oval at the top also changes. My goal is to keep the height constant regardless of topological changes to the overall shape. I've played with it on occasion, but never managed to get it right. There are numerous examples of database symbols on various stencils that can come close to what I need, but none of them retain a constant height of the not-oval when adjusting either the overall shape height and/or the width. Sure wish I knew someone who was retired and likes to take time to "solve intriguing problems". (Hint, hint. ;- )
- Ken
Fascinating!
My first thought for the barrel problem would be...
1) make the oval as a separate geometry section
2) let the width be controlled by the overall shape
3) oval thickness options
> use literal dimensions, not based upon geometry
> use a fixed ratio of the width
> use setatref with 2nd option to allow settable ratio (control point, data entry)
4) the upper end points of the vertical sides and the horizontal oval inflection points must "tied" together
Hope that helps
Here's simple cylinder implementation. Has placeholder for oval thickness...User.Thk. You can treat that however best suits your working style. :o ;)
Well, that was too simple. Kinda misbehaves with changes to oval height. So, here's an update. Seems to behave better. The culprit is the DCell in the elipse geometry rows. Took Excel analysis to curve fit the DCell values. This seems reasonably close with a 4th order equation. Whee!
It allows the oval height to be set via shape data. Double click the shape to get the entry form.
Wapperdude
Free time!!! Did you say FREE time!?!
Well, pardner, let me tell ya...
Attached is 3 segment version of the loquacious line shape. It also has Action menu to show either 1, 2, or all 3 segments. I've not noticed any unusual artifacts with this. Please let me know. Hmmm, is this a tax deductible political contribution?
Just asking.
Your lucky day... 2 out of 3 issues addressed (and solved???). Good thing for free time.
Wapperdude
.and here's a triple ending...
@Wapperdude,
I also suffer from free time ;) .
Had a look at your cylinder and was rude enough to think it could be improved.
Added a property angle to define from which angle the cylinder is seen. This way you can set the proportions of the ovals (x/y) to depend only on the width and the angle.
Did also add a control point to adjust the angle, but realised that it would end in a "ref-stuff" issue. May the "Master of references" have a look at it ;) ? (change prop.angle via the control point, while keeping the angle connection formulas set)
@Yacine: Not rude. There's no exclusivity. Besides, it's always nice to have options. The group approach is nice and clean. So, HeyKen has two solutions: one "integrated" and one grouped. Both work. Your approach is clearly easier to understand how it works.
Yeah, I hate that group - subgroup reference thing.
As I thought about it, there's no reference issue with the Cntl Pt, everything is done at group level. I modified your first shape to allow docmd(1312) and made it group only selection. Oh, removed the control point. Duplicated it, and made a Cntl Pt only version.
The attached file has all three versions.
@Wapperdude,
this is not really what I meant.
The control point shall define the view angle. The height of the oval is a function of the width and the angle ( = width * sin(angle)).
Now the control point being in the Y cell, to better show the correlation oval "height" to angle, depends on the height of the cylinder.
You could now set the angle as function of the control point alone, but you wouldn't be able to set its value manually in the shapes data.
That's where your "REF" wisdom could come in the game.
Cheers,
Y.
Hmmm. Now I am confused. I thought the control point goal was to provide another means of entering the angle in the sine fcn. Anyway, that's what I implemented. Thought it was too simple to be the solution. Ah, the light just went on...I didn't check this, and I'm not at my computer. But as implemented, the angle changes as both function of c control point and changes in height...oops.
Ok. That should be solvable with settler. Doh! Simple indeed!!! ::) My bad. :(
Error corrected!
Well, Yacine's control point idea is convenient, so, added it to my original shape. Plus, improved the elipse curvatures as elipse height / angle is varied.
... we're almost there :o .
Added some gimmiks ... and wishes (wishes, not requests! Thought you would enjoy some challenges ;) ).
Messrs. W. and Y:
So while I spent the weekend answering political surveys and filming TV commercials, you guys were having all the fun. Clearly, there's something out of kilter with my priorities.
The cylinder is virtually perfect! Exactly what I was looking for, except for one very important feature: it does not cater to my predilection for laziness. Why should I have to diddle the control point whenever I change the topology of the shape? Fortunately, it was a short step to correcting it: In the group's control point's Y cell, I substituted the elegant BOUND function for a blunt Height/Width*0.05. So now it stays the same constant height regardless of what I throw at it (at least for ratios less than 1, but that's far too minor to matter). Regardless, it solves my problem. Many thanks!! Remind me to cut your taxes.
As for that pesky articulated line, it's much closer to where it should be. Still needs the second arrowhead to be added plus some bounding on both arrows, but otherwise it's where it should be. I'll dig into all that after November 6th.
Thanks again!
- Ken
Adding double-arrowheads wasn't that difficult. It took 3 new geometry sections, one for each line segment. If you select double arrowheads from the GUI, it automatically gives them. There is a minimum spacing function that prevents the arrowheads from overlapping based upon lineweight and segment length. There is no adjustment based upon arrowhead size. If the length gets longer, the spacing will increase, as a percentage of that length. The arrowheads are spaced symmetrically about the control point. They are not independently placeable.
Wrt to limiting the range of the arrowhead placements, that bound to be a problem. It's a four quadrant issue. More than I care to get into at this point.
At a minimum, you have a starting place for doing the double arrowhead problem.
Then, there's this challenge to forum members...this development was based upon V2007. Since then, there's new features in the object model, to wit, point along a curve. So, the challenge is to re-work the approach using more up-to-date approach. :o ::)
Yep. There I've said it.
Wapperdude
Folks:
Of course when you have a solution in hand, you always try to improve it. So having a grouped solution, I took it further to attempt an ungrouped solution. Well, I found one – except for one basic problem: Fill doesn't fill the entire shape. I did some searching about, but to no avail. The best I found was an article by John Goldsmith (http://visualsignals.typepad.co.uk/vislog/2014/05/multiple-colors-in-a-single-visio-shape.html) that acknowledged my problem without saying how to correct it. He said, "By default, the boolean rules governing overlapping geometries means that the rectangle geometry will be given the fill and the three Ellipse geometries will be empty."
How do you change that default? I tried tricks with Join, Union, etc., but to no avail. All of them re-introduced the behavior the shape is meant to eliminate. I also tried replacing the ellipse (whose shape I like) with two elliptical arcs, but it has the same problem (aside from being less pretty).
My latest it attached containing both the grouped and ungrouped shapes. (You can ignore the untoward behavior of the ungrouped's bottom arc -- I know how to fix that, but there's no point in fixing a secondary problem until you fix the showstopper.) All I want is to have the color fill the entire ellipsy shape. Any suggestions? Besides "Give up!" that is?
- Ken
Here's ungrouped approach. I left the control point in to convenient set the oval height...orange shape 1st page. But, the height now remains constant with both width and height changes.
Well, while I'm at it., another, non-grouped option. Call this fun with fills.
The controlling cell is the GeometryXXX.NoFil cell. This cell, as previously mentioned, has a Boolean personality. So, where two geometry sections overlap, there lies the Boolean interaction. The fourth shape is designed such that there is maximal options:
1) Full shape fill
2) No shape fill
3) Only oval shape fill
4) Only cylinder wall fill
Just play with the true/false, i.e., 1 / 0, settings of the geometry.nofill cells.
Wapperdude
0.4886*User.Thk^-1.015?? Of course! Why didn't I think of that! It's so obvious! (NOT!)
Good plan, splitting my ellipse into two elliptical arcs. Understandable, and your piecing them together kept the illusion of an oval better than I could manage. It's that highly-intuitive 0.4886*User.Thk^-1.015 that did the trick.
We have a real winner here with your final shape, Wapperdude, what with the constant topologies, color choices and all. It's all I could ask for, and more! Thanks!!
Henceforth I shall refer to it as The Wappershape.
- Ken
...or perhaps wapper-thebull-dawg? ???
As for being intuitively obvious, well, it wasn't. I knew that cell helped keep things looking elliptical. But, was there a nice expression to define it. Trial and error with different settings proved that a linear relationship was unlikely. From my past life, when I earned money to make a living, I remembered using Excel to do curve fitting and finding trends. So, taking a proper amount of data points, I then let excel find the necessary equation. As they say in England...Brilliant! LOL.
The coloring scheme thing with the NoFill cell was again experience with such a thing. I have a JuneTheSecond post to help me recognize the interaction with multiple geometry sections. You, subsequently, found the John Goldsmith article.
To do really clever fill patterns, then you will need to use the grouped approach.
Dawgoneit!
Here's a new version. This is based upon feature incorporated with the newer Visio releases (those since V2007). I always had it in the back of my mind that the pointalongpath and nearestpointonpath could simplify this development. So, here it is. Note, as mentioned in a V2019 Issues post, the nearestpointonpath bug forced the use of grouped shapes, consequently, this isn't as clean as I hoped. But, it is much improved construction-wise.
This is a tri-articulated line, that can be either 1, 2, or 3 segments. Each segment has it's own control for moving an arrowhead. The arrowhead reverses direction at the segment mid point. The arrowhead can be either a single or double. The spacing of the arrowheads is proportional to the length of the segment. The Actions menu allows selection of single or double arrowheads, and 1, 2, or 3 line segments. All in all, this is much better behaved.
Wapperdude
Wapperdude:
Your latest result inspired me to dust off the less-than-ideal version I've been using, and I think I have exactly what I need. Like you, I finally resorted to using grouped shapes, and the final version meets all my requirements. It's 100% shapesheet and works in any version starting from 2003 (which is what I run at home) limited only by SETATREF support.
I took the single-segment arrowed line I've been using for years, grouped several together, and added some of the techniques from entangled shapes (http://visguy.com/vgforum/index.php?topic=8611.msg37527#msg37527), but instead of keeping the common attributes in TheDoc!User.whatever, I keep them in the group's User section. That makes it easy for all line segments to share the same attributes, and SETATREF lets you change them from any segment. It also makes it easier to reach the values via VBA. It's a three-segment line, but it's fairly easy to open the group and add additional segments as needed.
Check it out; it's attached, and as .vsd version for us Neanderthals. Suggestions welcome, as ever.
- Ken
Folks:
I've been using this articulated line for a few years now, and it's worked reasonably well. But I don't like how the bounding box looks. So my immediate goal is to have the box tight around the segments.
I'd prefer a DOCMD shapesheet solution to reset the box, but I couldn't locate one. However, I was able to do it by adding the following code:
Sub ResetAlignmentBox(TheShape As Shape)
TheShape.UpdateAlignmentBox
End Sub
I call the code by putting the following into its own user cell in the group-level shape:
=CALLTHIS("ThisDocument.ResetAlignmentBox","Tracer")+DEPENDSON(NOW())
' "Tracer" is the name of my stencil where the code resides
Whenever you move the line segments around, it fires and re-sizes the alignment box as expected. Yes, it does re-size the box once every minute as well, but I can live with that. Maybe. Read on...
All that said, this solution is not my preferred solution; it's just a hack that gets me close. What I really want is for the DEPENDSON to depend on the Width cell in any one of the group's subshapes. But I can't figure out how to reference the subshape's Width cell from within the grouped shape's shapesheet. You think it'd be a straightforward Sheet.nn!Width, but that keeps on giving me an error. What am I doing wrong?
Getting back to the DEPENDSON(NOW()), it likes to fire at odd times, not just once a minute. One of those odd times is when I save the master shape. The first time I try to save the shape Visio gives me an error, but the second time it saves it fine. But then when I save the stencil, Visio does the saving, but it still thinks the stencil is unsaved. Because the DEPENDSON fires whenever you save it? Beats me. All I know is I want the subshape Width reference there, not the NOW().
Always something!
- Ken
Should be doable in shapesheet. Two options, both in Misc. Section
1) Just hide the box: set NoAlignBox = True
or, more to your case:
2) set UpdateAlignBox = True.
docmd(1312) to present shape data.
Shape data field to show/hide (could just make it a command for that matter)
use show/hide to trigger shapesheet setting to show or hide specific stuff
Vojo:
Not sure I understand what you're suggesting. All I want is for the alignment box to show, and to automatically adjust whenever I move the line segments around. I used your DOCMD in place of NOW(), but it repeatedly asked me if I wanted to define user data. Not what I was looking for.
Wapper-man:
Not sure I understand you either. Setting UpdateAlignBox to True did nothing. I did it in all the segments and the group, with and without NoAlignBox, but the box doesn't cling to the segments.
To reiterate: My goal is to have the alignment box cling tightly to the line segments. Ideally, I want to change...
=CALLTHIS("ThisDocument.ResetAlignmentBox","Tracer")+DEPENDSON(NOW())
...to say...
=CALLTHIS("ThisDocument.ResetAlignmentBox","Tracer")+DEPENDSON(SubshapeOne!Width)+DEPENDSON(SubshapeTwo!Width)+DEPENDSON(SubshapeThree!Width)
...but I don't know how to access ""SubshapeOne!Width" from the grouped shape. Or SubshapeTwo and SubshapeThree, for that matter.
It turns out it doesn't matter, because I DO know how to access the group shape from the subshapes. So I turned the problem around. In the grouped shape (Sheet.17 in this example), I added three User section rows, SubshapeOne, SubshapeTwo, and SubshapeThree. I added a fourth row that says:
=CALLTHIS("ThisDocument.ResetAlignmentBox","Tracer")+DEPENDSON(User.SubshapeOne)+DEPENDSON(User.SubshapeTwo)+DEPENDSON(User.SubshapeThree)
Lastly, in the first subshape, I added a User.Cell with =SETF(GetRef(Sheet.17!User.SubshapeOne),Width), then SubshapeTwo and SubshapeThree, respectively.
That did it. Whenever any of the line segment lengths change, the new width is reflected on the grouped shape's user cell, and that user cell is used to trigger the DEPPENDSON. Problem solved.
Thanks again for the help!
- Ken
given that you think you can swap DOCMD for Now(), I think you got to do a lot more reading before you attempt what
you are attempting. Not insulting you, but if you think DOCMD does something similar to Now(), then some further research on Visio capabilities so that you can use all the tools in the toolbox.
Hey Ken...
That's odd, worked as expected for me.
Can you refresh my memory, which version of Visio, and upload copy of the shape? I have variety of versions, not sure we're synchronized.