We are migrating an application from C# to VB to meet our project's needs but stumbled upon a problem with event handling in VB.
The application uses a COM Wrapper access a scanner in Silverlight. The object is created dynamically in the code, and an event is added to "AcquirePage". This requires elevated trust of course.
Code in C#:
dynamic TwainSession;
(...)
TwainSession.AcquirePage += new AcquirePageDelegate(AcquirePageEventHandler);
As the only real "equivalent" of dynamic in VB is Object, we use:
Private TwainSession As Object
Everything is fine up to the point we want to handle an event of this Object. Because we are in Silverlight, we cannot have knowledge of the Object's structure or events, hence the need to create it dynamically. In C# we simply use "+=" to add a handler to an event but:
AddHandler TwainSession.AcquirePage, AddressOf AcquirePageEventHandler
In VB gives: 'AcquirePage' is not an event of 'Object'
Any way around that?
I think the answer is to compile with Option Strict Off but without being able to reproduce the problem I can't be sure.
See: Early and Late Binding
Unable to find a solution to do this within VB, we went about it this way:
Added a new project: Silverlight C# Class Library
The constructor takes two arguments, the dynamic object and the address of the event handler, and performs the C# method of adding handlers:
public TwainHandler(dynamic twainSession, Delegate eventHandler)
{
twainSession.AcquirePage += eventHandler;
}
The C# library was built and the dll added as a reference to the VB project.
Dim t as TwainHandler = New TwainHandler(TwainSession, New AcquirePageDelegate(AddressOf AcquirePageEventHandler))
This way the C# library adds the handler for the event (which points to a method in our VB application) dynamically. If anyone has a better solution please share.
Related
I'm trying to create a custom TitleBar for my game, i got everything else to work like i wanted but i can't get it to minimize without using the windows buttons from the windows frame.
I have a Game class with these in the constructor :
'Having this here or in the constructor doesn't make any difference
Public AsWindow As Windows.Forms.Form = CType(Windows.Forms.Form.FromHandle(Me.Window.Handle), Windows.Forms.Form)
Public Sub New()
Window.AllowUserResizing = False
Window.IsBorderless = True
end sub
Public Sub Minimize()
AsWindow.WindowState = System.Windows.Forms.FormWindowState.Minimized
End Sub
Calling Minimize cause a "System.NullReferenceException" on AsWindow, regardless of if i define AsWindow on runtime or during the initiation.
Note that i have added "System.Windows.Forms" as a reference.
Things i've tried:
This is where i got the initial code for the AsWindow field.
And here i tried to send a Message to minimize the window.
The problem you're facing is that the MonoGame API (which is exactly like XNA) doesn't expose a direct way of controlling the window. This kinda makes sense, because MonoGame supports platforms that don't have a concept of a "window" so to speak.
However, it's usually possible to get access to the underlying platform specific code and workaround these issues. It's important to keep in mind however that this approach will be platform specific and might break if MonoGame changes under the hood.
Last I checked, under the hood MonoGame uses SDL on the Windows desktop platform. This may not be true anymore, but I do have some code in an old project that gives the general idea. My code is in C# but it should point you in the right direction.
The first step is to import the method you want from the SDL.dll. This not managed code do you can't reference it like you normally would in .NET project.
[DllImport("SDL2.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern void SDL_MaximizeWindow(IntPtr window);
Once you have access to the method you can call it by passing in the window handle.
SDL_MaximizeWindow(Window.Handle);
Obviously, this is code to maximize the window (that's the only code I had handy) but I'm sure you can figure out how to do the minimize version yourself.
I'm just curious to know that there is the (Name) property, which represents the name of the Form class. This property is used within the namespace to uniquely identify the class that the Form is an instance of and, in the case of Visual Basic, is used to access the default instance of the form.
Now where this Default Instance come from, why can't C# have a equivalent method to this.
Also for example to show a form in C# we do something like this:
// Only method
Form1 frm = new Form1();
frm.Show();
But in VB.Net we have both ways to do it:
' First common method
Form1.Show()
' Second method
Dim frm As New Form1()
frm.Show()
My question comes from this first method. What is this Form1, is it an instance of Form1 or the Form1 class itself? Now as I mentioned above the Form name is the Default instance in VB.Net. But we also know that Form1 is a class defined in Designer so how can the names be same for both the Instance and class name?
If Form1 is a class then there is no (Static\Shared) method named Show().
So where does this method come from?
What difference they have in the generated IL?
And finally why can't C# have an equivalent of this?
This was added back to the language in the version of VB.NET that came with VS2005. By popular demand, VB6 programmers had a hard time with seeing the difference between a type and a reference to an object of that type. Form1 vs frm in your snippet. There's history for that, VB didn't get classes until VB4 while forms go all the way back to VB1. This is otherwise quite crippling to the programmer's mind, understanding that difference is very important to get a shot at writing effective object oriented code. A big part of the reason that C# doesn't have this.
You can get this back in C# as well, albeit that it won't be quite so clean because C# doesn't allow adding properties and methods to the global namespace like VB.NET does. You can add a bit of glue to your form code, like this:
public partial class Form2 : Form {
[ThreadStatic] private static Form2 instance;
public Form2() {
InitializeComponent();
instance = this;
}
public static Form2 Instance {
get {
if (instance == null) {
instance = new Form2();
instance.FormClosed += delegate { instance = null; };
}
return instance;
}
}
}
You can now use Form2.Instance in your code, just like you could use Form2 in VB.NET. The code in the if statement of the property getter should be moved into its own private method to make it efficient, I left it this way for clarity.
Incidentally, the [ThreadStatic] attribute in that snippet is what has made many VB.NET programmers give up threading in utter despair. A problem when the abstraction is leaky. You are really better off not doing this at all.
VB is adding a load of code into your project behind your back, basically.
The easiest way to see what's going on is to build a minimal project and look at it with Reflector. I've just created a new WinForms app with VB and added this class:
Public Class OtherClass
Public Sub Foo()
Form1.Show()
End Sub
End Class
The compiled code for Foo looks like this when decompiled as C#:
public void Foo()
{
MyProject.Forms.Form1.Show();
}
MyProject.Forms is a property in the generated MyProject class, of type MyForms. When you start diving into this you see quite large amounts of generated code in there.
C# could do all of this, of course - but it doesn't typically have a history of doing quite as much behind your back. It builds extra methods and types for things like anonymous types, iterator blocks, lambda expressions etc - but not in quite the same way that VB does here. All the code that C# builds corresponds to source code that you've written - just cleverly transformed.
There are arguments for both approaches, of course. Personally I prefer the C# approach, but that's probably no surprise. I don't see why there should be a way of accessing an instance of a form as if it was a singleton but only for forms... I like the language to work the same way whether I'm using GUI classes or anything else, basically.
At the moment I´m trying tests on the interoperability of VB6 and .NET using COM.
I have followed this simple example to call a .NET component from COM.
https://msdn.microsoft.com/en-us/library/ms973802.aspx
The DLL is registered and the assembly was "succesfully added to the cache". However when I take a look into the object browser of VB6 I can only see methods of the interface and not of the actual class. COM is set on visible and the correct path for the KeyFile, are both in the AssemblyInfo.vb file. The .NET Class+Interface looks like this:
Public Interface iTemperature
'some properties and functions
End Interface
Public Class NET_Temperature
Implements iTemperature
'some implemented public properties and functions
End Class
When I try to run the following Code:
Set moTempClass = New PhysServer2.NET_Temperature
Set moTemp = moTempClass
I´m getting the well known 429-runtime error, saying that creating an object through an Active-X-component does not work. There is a lot of information on the internet regarding this error with unregistered DLL/TLB, but I´m more concerned about the fact that only the methods and properties of the interface are shown in the object browser and not the implemented methods/properties of the interface - the class. How can I fix this Error and make the methods in my class sort of visible to COM and the object browser?
how does a gui application in qt5 runs, what is the ui pointers role in it. I'm new to qt pls help me,Why we will pass this in the constructor like, Ui->setup(this).Thanks in advance.
Long story short: the uic parses the xml that Qt Designer generates (from form you create into the designer) and creates C++ code from that xml, and you need to use that code into your window class, there are many ways you can use that code, see the documentation and using that ui pointer is one of those ways (actually that is a pointer to an instance of a class from the generated code) as for how setupUi actually works you can see into the generated code - short answer is: it creates the form's layouts and widgets as children of this.
I have a class MyProxy derived from RealProxy and implemented the bare minimum of Invoke to silence compile time errors. I inherit from MyProxy a custom class TabControl2 which itself wraps (ie: decorator) an TabControl.
I wish to call/intercept TabControl methods via the decorator - implementing everything myself as a learning exercize.
I understood the Invoke() of RealProxy would allow runtime interception of undefined methods in the decorator and call Invoke() with details of the invocation, such as method and arguments; thus allowing me to optionally invoke the original "decorated" object
I have googled for examples found many in C# and ported much of the code over to vb.
This particular bit of code is killing me:
Dim tabCtrlGeneric As TabControl = New TabControl()
Dim tabCtrlDecorator As TabControl = CType(New TabControlReorder(tabCtrlGeneric), TabControl)
Is giving me a compile time errors about type...not sure why?