The VariantArray function is side-steps the error but it seems clunky to have to do it myself.
Is there a native way to cast the strings to a variant in the the declaration, array(“one”, “two”) ?
Thanks
Var values() as Variant
values = Array("one", "two") //ERROR: expected variant but got string
//This works
values = VariantArray("one", "two")
Function VariantArray(ParamArray values As Variant) As Variant()
Var result() As Variant
For Each value As Variant in values
result.Add(value)
Next
Return result
End
Var ps As SqlitePreparedStatement
Var types(), values() As Variant
types = array(ps.SQLITE_TEXT, ps.SQLITE_TEXT)
values = VariantArray("one", "two")
ps.BindType(types)
ps.Bind(values)
This doesn’t appear to be a valid way to use that method - it doesn’t accept an array. Here’s what I would do:
Var ps As SqlitePreparedStatement
Var TypeValueBindings() as Pair
TypeValueBindings.Add ps.SQLITE_TEXT : "one"
TypeValueBindings.Add ps.SQLITE_TEXT : "two"
Var currentBinding as pair
For bindingIndex as integer = 0 to TypeValueBindings.LastIndex
currentBinding=TypeValueBindings(bindingIndex)
ps.Bind bindingIndex+1, currentBinding.left, currentBinding.right
next
Each binding is stored as a Pair with Pair.Left being the type and Pair.Right being the value. Then we loop through the list and bind each pair to the placeholder at index bindingIndex+1. If the index is 0-based, remove the +1 to correct it.
FYI, there’s a bug when doing a lot of constant to variant conversions that can cause terrible compilation performance when using Aggressive compilation.
Check the code completion hint at the bottom of the IDE. (2025 R2.1, MacOS.)
SQLitePreparedStatement.BindType(index As Integer, type As Integer)
SQLitePreparedStatement.BindType(types() As Integer)
Tbf I missed the word ‘integer’ when I transcribed to the forum, so my apologies for that.
Var types() As Integer, values() As Variant
It’s working fine and it never occurred to me it might not work. It was the values array that tripped me up. I’ve since checked the documentation and it doesn’t appear to be in there.
At some point Xojo will need to get rid of variants as VB did, and prepare the user base for a transition.
Visual Basic (VB) got rid of the Variant data type in the transition to VB.NET (specifically with the release of the .NET framework in 2002) to align with modern programming standards, improve performance, and enhance type safety. The Variant type was replaced by the Object data type in VB.NET.
The decision to remove Variant was driven by several technical and design goals:
Improved Performance:Variant variables used more memory (16 bytes for a numeric, 22+ bytes for a string) and were slower to access than explicitly typed variables. VB.NET aimed for better performance, and strongly typed variables allowed for more efficient code execution within the Common Language Runtime (CLR).
Enhanced Type Safety and Reliability:Variant allowed variables to hold any type of data, which provided flexibility but increased the risk of runtime errors and hard-to-detect bugs that only appeared during execution. VB.NET is a strongly typed language, which means data types are checked at compile time, leading to more reliable and robust applications.
Alignment with the .NET Framework: The Variant type was deeply tied to the COM (Component Object Model) infrastructure used by older VB versions. The .NET framework introduced a new, fully object-oriented environment where all types inherit from a common Object base class. Replacing Variant with Object was essential for seamless integration with the rest of the .NET ecosystem (including other languages like C#) and its features, such as inheritance and threading.
Better Code Maintainability: Explicitly declaring data types makes code easier to read, understand, and maintain, as the intended use of a variable is clear from its declaration.
How the Variant Data Type Was Removed?
Microsoft handled the removal as part of the significant language redesign when migrating from VB6 to VB.NET.
Replacement with Object: In VB.NET, the Object data type serves a similar conceptual role as it can technically hold any value. However, the Object type has differences from Variant (e.g., Object variables cannot directly hold the special Empty, Null, or Missing values from VB6).
Migration and Obsolete Keyword: When migrating older VB6 code to VB.NET, the Variant keyword is no longer supported and the code editor replaces it with the Object type automatically. The Variant keyword still exists as a reserved word but has no functional meaning.
Encouraging Explicit Typing: The move to VB.NET strongly encouraged developers to use specific data types (e.g., Integer, String, Double) instead of relying on a generic, untyped approach. The Option Explicit setting, which forces variable declaration, became more critical.
No Direct Conversion Path: No direct, automatic conversion existed between the old Variant type and the new Object type, requiring developers to use specific NET marshalling techniques or rewrite code to handle the types correctly when interoperating with legacy COM objects.
This change made the VB’s evolution from a dynamically typed, COM-based language, to a modern, statically typed, and safer object-oriented language.
You forgetting that it really were the Generics that came in .NET 2.0 that replaced the variant as the situation was clunky before 2.0 with Object carrying it all.
It’s hard to see how much of that relates to a more modern language like Xojo. We don’t worry too much about memory these days, especially when talking about a difference of a few bytes per reference, and computers are so damn quick that we are willing to overlook a few extra cycles to access them. Yes, it’s a good idea to strictly type your code, but there are good reasons to have a Variant-like option, as long as less-experienced users are strongly encouraged to pretend it doesn’t exist.
My reasons for keeping Variant around are more foundational to the Xojo language. Intrinsics like string and integer don’t inherit from Object, and arrays exist in some quasi-Object limboland. If we didn’t have Variant or something very similar, the language would have to be refactored so you could do something like:
Var myArrayOfRandomStuff() as Object
myArrayOfRandomStuff.Add 1
myArrayOfRandomStuff.Add “bogus”
myArrayOfRandomStuff.Add New Class1(“deez nutz”)
Frankly, this would be an interesting place for the language to go and would open up a lot of generic functionality that we currently lack – the treatment of arrays in Xojo has for decades driven me bonkers, for example. A generic Array class, inheriting from Object and able to manipulate its contents in a class-agnostic fashion, would be an absolute godsend in some situations I’ve run into. That’s often why we end up looping through our arrays and casting them as Variants or superclasses for use in generic code.
No, thanks. I work a lot with dictionaries as method for communication inside my apps so I need variants.
Some years ago I did a lot of VBA. It was possible to do write really stupid code with the variants because the language was so botched. Improving that may make sense for VB.Net. But in Xojo I’d like to keep working with variants.
Variants are not “modern”, they were a 90’s way discarded in 2002. They are despised by the current modern standards.
Nope. I’m not. I just focused in the simple part of the evolution. Xojo reaching Generics will take more time.
Generics (List(Of T), IEnumerable(Of T), etc.) were introduced in .NET 2.0 to address a different set of challenges, primarily with collections. They are not a direct replacement for a Variant variable but rather an alternative to non-generic collection classes that used Object internally (like ArrayList).
Nope. You don’t need. You just need to relearn how to use objects instead of variants.
' VB.Net, Xojo will have their own way
Dim mixedValues As New Dictionary(Of String, Object)
' Adding different types of values
mixedValues.Add("UserName", "JohnDoe") ' Storing a String
mixedValues.Add("UserAge", 30) ' Storing an Integer
mixedValues.Add("IsActive", True) ' Storing a Boolean
I didn’t say they are modern. I said Xojo is a modern language compared to the 2002 version of VB that dropped variants. The concerns listed in your post included items such as “variants use more memory” and “take more time to access” - both of which would have been much more concerning in 2002’s computing landscape than 2025’s.
And 2002 VB couldn’t compile for ARM, or Raspberry PI, or any Mac platform, and doesn’t support modern UI standards, and doesn’t support modern encryption standards, and and and… now who’s the more modern language? Two can play at the cherry-picking game but neither can win.
