I've been working on a macro which, in part, gets info from various cells in the shapesheet.
for the last hour I've been going nuts because a simple line of code was not working. I have a string variable called designator that I want to fill with the value from a cell as such:
Designator = visShape.Cells("Prop.GADesignator")
but this always returned "0", even though there was a string in the cell. Then for the heck of it I tried this:
Designator = visShape.Cells("Prop.GADesignator").ResultStr(Visio.VisUnitCodes.visNoCast)
and got the value I was expecting! the first example, without the resultstr works fine on pretty much all the other cells I'm getting data from, just not on the "designator" cell.
can anyone tell me why this is behaving this way?
should I just make it a habit to always use the resultstr version?
thanks!
It's a bit of badly implemented object handling in the internals of VBA, the item
visShape.Cells("Prop.GADesignator")
is really only a reference to a cell, it shouldn't return the cell contents.
As you've noticed, to get the cell contents us
visShape.Cells("Prop.GADesignator").Result
visShape.Cells("Prop.GADesignator").ResultStr
or
visShape.Cells("Prop.GADesignator").ResulIU
and maybe others I've forgotten about.
However, the first version (without the .resultstr) does work in many cases. It is often shown in Microsoft's own examples!
So then is it safe to say that one of the .resultstr versions should typically be used?
Interesting.
Fundamentally, to get a result, it is my understanding you always need the appropriate ".result".
Can you post one of the links that you refer to?
Wapperdude
visShape.Cells("Prop.GADesignator")
should be the same as
visShape.Cells("Prop.GADesignator").ResultIU
as ResultIU is the default method of the Cell class.
@AndyW: Default method. ??? Had no idea!
It is a VB thing, you can mark a method as the default via the Tools, Procedure attributes.
You can also do this in VBA but requires export of class, edit with text editor to add the following line to the method that is to be the default.
Attribute Value.VB_UserMemId = 0
And then re-import the class.
That's more about VB than I ever need to know! ::) :D
To go along with the "default" point, here's this link for those whom might be as uninformed as myself: https://msdn.microsoft.com/en-us/library/ms368327(v=office.12).aspx (https://msdn.microsoft.com/en-us/library/ms368327(v=office.12).aspx)
While I appreciate the convenience of "defaults", and, perhaps it has merit for full-time programming on a large scale, in general, I think "un-declared" defaults are "bad form"...just personal opinion. Defaults would just seem to add to confusion of understanding the code, much like lack of comments. But, I don't do it for a living, some might look at my code and say I don't do it all :(, so, no offense meant to full time "coders".
Wapperdude
That's why a control "myText" can be assigned directly a value, whilst the strict way would be to assign it to "myText.value".
And that's also why real programmers turn up their nose at VB.
then I guess I should always use the .resultstr if I am looking to get a string!
@Perry: Yes. Good habit is to use explicit call, that way, you and any code viewer, know exactly what you're getting now and into the future (when memories fade and the question comes to mind...What did I do? What was I thinking.)
@Yacine: Ouch! :o :D Well, it is possible to carry over good programming habits, even if VB doesn't require them. Plus, the macro recorder gives you VBA, so, it does kinda push you into the VBA realm. ::)
As long as it works ... isn't it?
On the other hand, the more you code, the more you discipline yourself. You learn that debugging is so much more time intensive than the actual coding, that you try to do it right the first time. (my codes now alway begin with option explicit)
;)
I wasn't implying that it was a good feature, just that it is there and how it works.
I used to turn my nose up a VB when using real programming languages, well in fact anything Microsoft when I was also using real operating systems. Unfortunately I have spent the last 10 years using VB/VBA. Although Visio turns out to be great (which is why the 10 years VB), but then that wasn't an MS product to begin with!!!
poor M$. ;)
Guess it is not that the products are so bad, it's rather their dominant position that makes them intrinsically bad.