As a challenge to myself, I've created a Visual Basic app that uses the Microsoft Bot Framework and LUIS API. To my own amusement, I've largely gotten it working .. almost.
After getting over some C# to VB hurdles, there's one I can't get over, which is stopping my app from keeping the conversation stack from functioning properly (it bails out after one interaction).
Specifically, I have the following code fragment inside of my dialog code:
Imports System
Imports System.Threading.Tasks
Imports Microsoft.Bot.Builder.Dialogs
Imports Microsoft.Bot.Builder.Luis
Imports Microsoft.Bot.Builder.Luis.Models
<LuisModel(“xxxxxxxxxxxxxxxxxxxxxxxxxx”, "xxxxxxxxxxxxxxxxxxxxxxxxxx")>
<Serializable>
Public Class MyLuisDialog
Inherits LuisDialog(Of Object)
<LuisIntent("None")>
Public Async Function NoneIntent(context As IDialogContext, result As LuisResult) As Task
Await context.PostAsync(“this is boring chat ..“)
context.Wait(MessageReceived)
End Function
but I cannot interpret the context.wait(MessageReceived) from C# into VB.
The compiler wants to do:
context.wait(MessageReceived(context,????????))
but I cannot figure out what to put in for ?????.
Irritatingly, the C# version just works in the form context.wait(MessageReceived).
Assistance as to what syntax/code should be used when using VB gratefully accepted :)
Try with context.Wait(AddressOf MessageReceived)
Related
I 'am trying to use this code (posted 11 years ago !), and I have problems with the vb.net version. I have solved a lot of compilation errors, but I can't solve this one :
MyBase.Child = box
Which returns the error 'Cannot convert a value of type 'TextBox' to 'UIElement'. I tried casting and a lot of other things, but as a real newbie I don't understand what could be wrong. And as a newbie on this forum, I can't ask within a comment in the original question...
In the question you linked to, the accepted answer contains code for a class that inherits ElementHost, which is a WinForms class that exists specifically to host WPF controls. That means that the TextBox in that code is a WPF TextBox. Note the namespace imports in that code. It's the System.Windows.Controls.TextBox control that is being used. I suspect that you either don't have that namespace imported or have the System.Windows.Forms namespace imported preferentially and thus, in your code, TextBox is actually being interpreted as System.Windows.Forms.TextBox.
I am trying to build a COM Add-In and I get the errors:
'IDTExtensibility2' is ambiguous in the namespace 'Extensibility'.
'ext_DisconnectMode' is ambiguous in the namespace 'Extensibility'.
'ext_ConnectMode' is ambiguous in the namespace 'Extensibility'.
My imports are as follows:
Imports Extensibility
Imports System.Runtime.InteropServices
Imports Microsoft.Office.Interop
Imports Microsoft.Office.Interop.Excel
Imports Microsoft.Office.Core
I used the shared add-in wizard in VS 2010 and I am using VB.NET.
The codes that have errors are anything that contains:
Extensibility.IDTExtensibility2
I couldn't find this anywhere and I figured the wizard would work without errors. Any thoughts? Thank you.
Check whether one of the Microsoft.* namespaces already imports the Extensibility namespace.
If not, there is possibly an upper-/lowercase ambiguity, try whether you can access the class in C# or through reflection.
If it still does not works, there probably goes something wrong during interop proxy generation but then it get's complicated, you have to use the tlbimp.exe tool and toy around with its options.
I have written some classes in visual basic.net and want to use them in a visual basic 6 application.
Now I have registered the tlb/dll files on my computer and I am able to create an instance of the class in vb6 with
Dim c As New Advantage_Dealer_Email_CoreClassLibrary.CoreClass
However I want to use CreateObject(Class) but when I try I get the ActiveX error, here is the code I am using for that
Dim c As Object
Set c = CreateObject("Advantage.Dealer.Email.CoreClassLibrary.CoreClass")
Is this possible what am I doing wrong?
Thanks
Update:
After searching through the registry I am only able to find a CLSID which references Advantage.Dealer.Email.CoreClassLibrary.
{CFB8F7A1-BC6F-4771-839F-1343785ED9D6} > 1.0 > (Default) REG_SZ Advantage.Dealer.Email.CoreClassLibrary
Solution
I had another look in the registry and found a Guid called
CoreClassInterface
which referenced the library, when I used the code
CreateObject("CoreClassInterface")
the vb6 program worked.
For anyone that comes across this post in the future it was because I had set the ProgID in the vb.net class when setting up the class with an interface for the Com Interop.
<Guid("7EB55A33-34E7-4FC4-A87B-41635EEAF32D"), ClassInterface(ClassInterfaceType.None), ProgId("CommClassInterface")> Public Class CoreClass : Implements _CoreClassInterface
After removing the ProgID for the class and rebuilding/registering the library on my computer I found
Advantage.Dealer.Email.CoreClassLibrary.CoreClass
In the Registry, and my vb6 app worked.
Thanks for your help tcarvin
I find it best, when creating .NET libraries for consumption by VB6, to keep the namespace of COM-visible classes to only one-layer deep to avoid the underscores. Anyway, have you attempted to use:
CreateObject("Advantage_Dealer_Email_CoreClassLibrary.CoreClass")
When all else fails, the answer is in your registry. Use regedit and see what the component is listed under.
Ladies and gentlemen,
I am trying to create a DLL I can share between a few different projects that includes a variety of extension methods I've written to simplify my code. In understand such DLL's are feasable to share between C# and VB.net projects. I however have been unable thus far to create a DLL, or even to include the sub project and reference it that way and be able to access my extensions.
I am able to see the reference in the object browser, but import statements do not bring up my sub-project reference as an option. VB.net does not allow me to place the extensions within classes, and I can't seem to find any clues on the web that would explain this. Thanks in advance.
Example...
Imports System.Runtime.CompilerServices
Imports System.Text.RegularExpressions
Module Extensions
<System.Runtime.CompilerServices.Extension()>
Public Function ToEnum(Of T)(ByVal value As String) As T
Try
Return (CType([Enum].Parse(GetType(T), value.Replace(" ", ""), True), T))
Catch ex As Exception
Return (CType([Enum].Parse(GetType(T), 0, True), T))
End Try
End Function
End Module
You need to mark your Extensions module with the Public keyword. Also, make sure that your project properties in your consuming project lists your library project as a reference; simply appearing in the Object Browser doesn't mean you've set up the reference properly.
The following console application code is perhaps nonsensical, but leverages your exact code above with the exception that I made your module Public versus the default of Friend.
In my solution, ClassLibrary3 is the VB class library project and included as a reference in the console application project.
Imports ClassLibrary3.Extensions
Module Module1
Sub Main()
Dim f As String = "hello"
Console.WriteLine(f.ToEnum(Of System.ConsoleColor)())
End Sub
End Module
Is it better to use friend or public forms in vb.net? What are the advantages of each?
I notice when you import a vb6 project, the forms come in as friend, but when you add a new form in vb.net it is public. I have not seen any difference in the way they work, though, so I must be missing something.
In my opinion, I would use Friend (aka internal in C#) even though the default is public. I would also use private for controls on the form even though I think VB defaults to protected. In general, think of type/member access as if it were your wife's boobs. Keep them hidden from others up unless there's some benefit to exposing them (like getting out of a speeding ticket or making a shared library of common dialogs, etc.)
One drawback with making things internal is that you have to do some extra work to make them public to your unit tests. See the InternalsVisibleToAttribute for details.
VB6 did not support exporting forms from a class library. The natural mapping for converted code therefore is Friend. However, VB.NET has no such problems. Using Public is fine, assuming any exposed types in public method arguments is Public as well. Easy to find, the compiler will tell you.
If the form is Public it can be accessed from outside the current assembly (.exe). If it's Friend then it's only accessible from within the assembly. The same access level rules apply to Forms as other VB.NET classes.
I can't think of a common Winforms situation where you would need public Forms because they're usually in the same assembly making friend good enough. Unless you had forms scattered through different assemblies and they needed to reference one another.
Maybe the Microsoft team that wrote the import tool decided on Friend because all the forms came from the same classic project, whereas the Visual Studio (New Item) team decided on Public because the .NET way deals more with modularized projects. It might just be as simple as that.