From a .NET VSTO add-in I wonder if when I read a boolean field, when I retrieve the FormulaU or ResultSTR(231) and get a string of "TRUE" or "FALSE" returned whether this will work when Visio is used in other languages. Does automation get a different string returned in some other languages?
To be safe I just get the ResultIU when retrieving a boolean so I just check for false (0), but wonder what is returned in Visio when the software is set to other languages? (is this a good way to go about reading boolean values?)
I notice that if I get a ResultStr(32), where 32 is the setting for number, I do not get a "0" for FALSE but the string "FALSE". Since when is the string "FALSE" a number?
See: https://learn.microsoft.com/en-us/office/vba/api/visio.visunitcodes
Very good topic.
My standards when working with Access:
- Reading: rsData(field) = Left(shp.Cells("prop." & field).resultstr(0), 255) 'I crop the value to 255
- Writing: shp.Cells("prop." & fieldName).formulau = Chr(34) & Nz(Me.Form.Controls.item(fieldName).Value, "") & Chr(34)
This covers every field including booleans. That means I don't care whether the user writes a 0,1,TRUE or FALSE. Incorrect values (3, "my green apple",..) are caught by an error handler, that resumes to the next step.
There certainly better ways. Looking forward to read what our "colleagues" write.
In my VSTO Addin I use:
bool result = Convert.ToBoolean(shape.Cells["Prop.Result"].ResultIU);
Don't know if this is the best way, but it works at least with English and German Visio / Windows.
Because I find that confusing and to much text (first check if a cell exists and then the code above) I use helper functions in a static class:
if (VShape.IsArticle(shape)) { ... }
I remember a language issue with boolean value in a VBA project.
On German systems we had errors after passing a boolean value to a Sub that accepted this parameter as variant.
As fix we converted the boolean to integer before calling the Sub.
To add to Thomas' post.
1) convert.to boolean: https://learn.microsoft.com/en-us/dotnet/api/system.convert.toboolean?view=net-7.0 (https://learn.microsoft.com/en-us/dotnet/api/system.convert.toboolean?view=net-7.0)
2) I too often wondered why .FormulaU was throwing errors. I would then take the result, replace commas by dots, then write to the formula.
Use .Formula instead for better localisation.
Quote from: Thomas Winkel on May 24, 2023, 12:16:11 PM
As fix we converted the boolean to integer before calling the Sub.
You mean: a separate row user.something, formula =if(user.boolean,1,0)?
Yacine using FormulaU in VBA or an add-in, from an add-in? In an add-in, Formula(Force)U works fine for me every time.
Quote from: Visisthebest on May 25, 2023, 07:53:44 AM
Yacine using FormulaU in VBA or an add-in, from an add-in? In an add-in, Formula(Force)U works fine for me every time.
Usually in Python (can't remember abt. VBA). floats get sent with commas as digital separators instead of dots.
Quote from: hidden layer on May 25, 2023, 07:08:07 AM
You mean: a separate row user.something, formula =if(user.boolean,1,0)?
Not in ShapeSheet, but in VBA.
Here is the shortened code:
Public Sub Checkbox_onAction(control As IRibbonControl, pressed As Boolean)
' Translate boolean to fix german visio bug (true -> wahr, false -> falsch)
Dim intPressed As Integer
If pressed = True Then
intPressed = 1
Else
intPressed = 0
End If
Select Case control.id
Case "LooseMappingsOnCopy"
VDocument.SetProperty ActiveDocument, "LooseMappingsOnCopy", visPropTypeBool, intPressed
'...
End Select
objRibbon.invalidate
End Sub
Public Sub SetProperty(doc As Document, propName As String, propType As Integer, Value As Variant)
If Not doc.DocumentSheet.SectionExists(visSectionProp, True) Then
doc.DocumentSheet.AddSection (visSectionProp)
End If
If Not doc.DocumentSheet.CellExists("Prop." & propName, True) Then
doc.DocumentSheet.AddNamedRow visSectionProp, propName, 0
doc.DocumentSheet.Cells("Prop." & propName & ".Type").Formula = propType
End If
doc.DocumentSheet.Cells("Prop." & propName).Formula = Chr(34) & Value & Chr(34)
End Sub
The fix was done by a colleague with a German installation 12 years ago, so I never looked into it.
When I see this now I think that encapsulation "Value" with Chr(34) will only work proper for string types.
Also, I don't think it crashed, it just did not work.
The better fix would be to handle "Value" depending on "propType" in SetProperty.