POINTALONGPATH / ANGLEALONGPATH bug?

Started by ngrison, May 09, 2016, 02:58:30 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ngrison

Hi all,

I have a diagram with many connectors and attached labels. The positions of the labels are determined with the POINTALONGPATH and ANGLEALONGPATH functions. It always work when working on the file, but after saving and re-opening the file some of the labels will move to unexpected positions.

I've tried to figure out what is going on and it looks like in some cases the functions, when the file is just open, don't retrun the right value. In fact, for the points located on the first 50% of the path it seems to be fine, but for points on the next 50% the position returned are somehow "symetrical" from what they should be.

As soon as I move a shape the connector is attached to things get back to normal, even if I revert with ctrl-z. Same if I go into the shapesheet and revalidate the formula. Also if the file is in Visio 2010 format all is fine.

I was wondering if any of you have experienced that problem? I have seen a few posts mentionning the connectors being incorrect until a shape is moved, fixed in SP1. I am wondering if this is not the same issue but those functions didn't get fixed with the rest. Right now, the only workaround I have found is a VBA macro run when the file is open that rewrite the formulas but this is a huge kludge...

Thanks a lot!

JuneTheSecond

Best Regards,

Junichi Yoda
http://june.minibird.jp/

JuneTheSecond

#2
And here is my result on Visio Guy's example where the every trip is set to 0.5.
Best Regards,

Junichi Yoda
http://june.minibird.jp/

CraigPatCT

Hi ngrison, and anyone else with this issue,

I know this is an old topic, but it's new to me because I have been experiencing exactly the same problem with my copy of Visio 2013. Whilst I have come across others with seemingly random behaviour of the POINTALONGPATH function, your post here is the only one I have read which describes my issue exactly.

Another note to add to this is that this issue is still present in Visio 2016, and therefore presumably 2019 as well, but I cannot confirm this.

Also, I have noticed the exact same problem with the PATHLENGTH function.

Oddly, on a single drawing with say, 50 smart connectors using multiple labels, about a third will not be showing their end labels until an end of the connecter is moved in some manner, causing an event to force recalculation of the aforementioned functions. I can then save the drawing with all labels displayed, but upon re-opening the exact same connectors will be missing their end labels, which due to the logic in the formulae just means these functions need to be triggered again.

In case you're wondering, the difference between a working connector and a faulty one cannot be found on the drawing page, or in the ShapeSheet; they appear to be identical, except they have different ID numbers.

This problem is repeatable across numerous computers using either 2013 or 2016.

Have you found the cause and a solution yet?

For my own work I had to either find a fix or a workaround, but either way I still needed to use these functions.

So after much debugging and manually triggering the functions in a wide variety of order throughout the faulty connector's ShapeSheet, I then spent a lot of additional time trying to learn how the functions were actually triggered, without much success I'm afraid, but due to my very limited experience in coding with C and VHDL, I did get the feeling from what I've been reading that this problem might be caused by a memory reference issue within Visio. So I had a thought to try deleting the problem row and creating a new row to create a new reference to a memory location, and this worked. So then I tried renaming the same original problem row (in another copy of the faulty drawing) to something else, and this worked as well. So then I tried just renaming the Row which holds the offending function with it's original name; i.e. without changing the name, and it worked as well. So now I appear to have fixed the problem permanently for that connector; for good :)

After further investigation and testing I found that I actually needed to rename three rows in the ShapeSheet for this particular connector; two had a POINTALONGPATH function, and the third had a PATHLENGTH function. Each of these three rows were returning values of zero upon opening the document, which was wrong. However, after renaming the rows, saving the document and re-opening, they worked reliably from then on.

Just to be clear, I renamed User.EndPnt to User.EndPnt, and didn't touch the formula in the Value cell. In fact, all I had to do was copy the label and simply paste it over itself and problem gone.

So I whipped up a routine to delete and replace the same offending rows in all connectors throughout the drawing, and I haven't seen the problem since. I have since updated the master connector in the stencil and the problem has not reappeared (yet).

I think during my development of the formulae and code behind the shapes I'm building, using ideas and snippets from this forum, John Goldsmith's (where User.EndPnt came from), David Parker's, and occasionally others including MSDN (thanks to everyone for your dedication to smart drawing), it looks to me like I have somehow corrupted the internal references to some of the connectors' User-defined Cells, preventing them from being processed upon opening or refreshing the document page. If this is the case, I expect to come across other hard to explain bugs, and if I do I'm now hoping to have a potential solution, or a direction in which to start looking.

Hope this helps someone.

Craig




wapperdude

The following attachment works in V2019.  I suspect the issue is the instantiation method for the pointalong path.  See shapesheet.  This approach was adapted from VisioGuy.
Visio 2019 Pro

CraigPatCT

Thanks, wapperdude, for the sample.

I have experimented with this type of label alignment along a connector after I came across the lesson in VisioGuy whilst looking for a resolution to my problem, but it always worked without issue. I think it's a great feature though and may use a part of the concept in future projects, depending upon what my customers want.

When I initially created my connectors they worked reliably. I then put them aside to work on other areas of the project, but when I later came to the point of using the connectors in schematics for my customers I discovered this issue.

Whilst developing the other smart components for the schematics I experienced many Visio crashes, mostly caused by me creating loops when experimenting, and sometimes I needed to fudge my way back to a working document after a crash because I hadn't saved the last few changes and I didn't want to create the code or formulae from scratch again. These crashes are the only thing I can think of which may have affected the seemingly random selection of connectors. It's possible the affected connectors were on the page when the crashes occurred, and as I wasn't working on them specifically I had seen no reason to replace them as the schematic came together.

This is why I don't yet blame Visio for the POINTALONGPATH issue that several people have come across. Instead, I think, at least in this instance, I broke something in Visio's internal references during the loop crashes, and I suspect the other developers who have similar issues may have done something similar, but not realised a previous unrelated crash might be the cause of an issue with the POINTALONGPATH or PATHLENGTH functions.

I use 2013 Pro 32bit at work for the bulk of this work (pushing ICT for an upgrade). I personally own 2016 Pro, 32bit and 64bit at home where I regularly test. I saw no difference in the behaviour of the affected connectors between the three versions.

One of my customers has just setup a PC with 2019 Pro for me to use for testing their version of the smart schematics I've been commissioned to create. I still have a copy of the previous schematic with the faulty connectors and will run some tests to see if this issue remains or has vanished in 2019 without my intervention. I'll report back here with the results either way as someone might find them useful.

Craig