I am currently designing the migration of my existing .NET / C# / WinForms project to a platform neutral solution and the most attractive alternative I have seen seems to be wxWidgets especially taking in consideration my familiarity with C++ and with MFC that appears to have a lot in common with it.
After going though the documentation and the sample code I need to clarify the following issue:
Is it a valid assumption that the way to develop a User Control (by C# terminology) in a wx environment is to derive a class from wxPanel , customize it and place it in a wxFrame?
If this is the case what is the wxFrame method to be used to add the wxPanel object to it ?
The only relative method I was able to find was wxWindow::AddChild but the documentation states that is mostly internal to wxWidgets and shouldn't be called by the user code.
To avoid confusion please note that my question is about a User Control and not a Custom Control (which is clearly addressed in the documentation)
I think you have to set the parent window in the constructor of your wxPanel-derived class and pass it to the inherited constructor (cf. wxPanel constructor)
A better solution, though, is to use sizers (see wx Sizers) for layouting.
And yes, imo you're right about wxPanelbeing (roughly) the equivalent of a C# UserControl.
Related
MS Word has a very useful mechanism to wrap up its dialog boxes to use via COM or .Net. You can execute a "Display" method - which does the obvious - and also an "Execute" method which is equivalent to pressing "OK". I have a legacy MFC app which I am attempting to attach a COM object model to for scripting and regression testing, and I would like to do the same thing. It has a number of dialogs that I want to control programmatically from my test harness. It's been years since I really delved into MFC, and I can't find anything useful on t'internet so far.
My guess would be to wrap up the CDialog derived classes, perhaps within an ATL class (ATL is used extensively in the project), but I have a suspicion that there may be a better way.
Worst case scenario, I'll move the dialogs to C# and make them COMVisible (which is probably more strategic), but that's going to be more work.
Any thoughts and help appreciated - obviously this is rather antiquated technology!
All CDialog derived classes in MFC are a subclass of CCmdTarget.
CCmdTarget is the baseclass for MFC COM functionality.
There is a lot of work you have to do under the hood. You should define and IDL file for your interfaces, compile the IDL, and then have the compiled typelibrary be a resource in your program.
There are helper macros for your CCmdTarget derived classes like:
DECLARE_INTERFACE_MAP()
BEGIN_INTERFACE_PART()
END_INTERFACE_PART()
BEGIN_INTERFACE_MAP()
INTERFACE_PART()
END_INTERFACE_MAP()
I would say that if you want to see how MFC does it, use the App Wizard and generate an MFC application that has OLE Automation enabled and then look at the generated code. It will show you what you need to wire up your MFC app for OLE Automation.
I'm programming Windows COM in C++ and I see that a lot of functions get prefixed with :: so that the global namespace version got called. Why is that?
I understand that there may be conflicts with namespaces, but does it happen so often in COM that everyone has become so paranoid that every single function now has to be resolved explicitly?
Here are some examples that I see often:
wStrLen = ::SysAllocStringLen(NULL, wStr);
::SysFreeString(str);
::CoTaskMemFree(item);
And many others.
It just puzzles me why the programmers chose to resolve namespace explicitly and why they didn't just write:
wStrLen = SysAllocStringLen(NULL, wStr);
SysFreeString(str);
CoTaskMemFree(item);
Any ideas?
No, that's not common in COM programming, not in any I wrote or studied anyway. COM itself adds few names to the global namespace, there are not that many helper functions. A common way to implement a COM interface is to use a C++ class, you can stick it in any namespace you like since it doesn't get exposed at all outside of the module. I suspect that it is just something the team whose code you saw preferred. If you saw it in a book then that's a good way to increase the odds that the book code sample can drop into an existing program without too much trouble. There's otherwise nothing wrong with it.
I wrote a little ActiveX control in VisualBasic 6 which is going to be used as a plugin for some 3rd party framework. The framework expects that my control exposes a few properties and methods. It all seems to work well except that one of my properties seems to be ignored.
In C++, I could put debug statement into the reimplementations of IDispatch::GetIDsOfNames and IDispatch::Invoke to see which members the framework attempts to access - maybe the documentation is wrong, and it's expecting a different property name or something.
Is it possible to monitor the accesses to COM properties/methods in Visual Basic 6, too?
The easiest way is to add logging of some form in the methods/properties in question. I don't think you can hook the lower level COM calls though.
For the logging, you can use OutputDebugString().
There's a rather old 'Hardcore Visual Basic' book around that teaches you exactly how to implement IUnknown, IDispatch etc. in VB5/6.
I know that when you add/change/remove methods in a COM interface you're supposed to change the interface/coclass GUID but what about type libraries. When should you change the type library's GUID? Do you change it if a GUID inside the type library has changed? Or should you only change it when something that doesn't have its own GUID within the type library changes.
The basic principle is that COM interfaces and Type Libraries should be immutable (that is, they shouldn't ever change). If you change one item inside a COM interface, then the new version needs to be a completely separate entity from the previous version. The only way to do this is to change the GUID for every interface in the library and the GUID for the type library itself. It's also a good idea (for your own personal sanity) to change the name of the type library.
Ideally you shouldn't ever change a COM interface. Instead create a new derived COM interface and publish in a new type library.
I've got a similar question.
I had an original control with CLSID_A that implemented interface IID_A in some 1.0 type library with GUID_A
Later on, I decided to add a new interface to the original control. It would then implement both IID_A and IID_B interfaces. I figured that I should probably keep the same CLSID but didn’t knew much what to do with the typelib itself. I was mostly doing VC++ programmatic-by-the-book stuff which involved QueryInterface and didn’t cared much about versioning and typelib. You wanted to create an object with a specific CLSID, you just asked CoCreated instance...and then Queried interface for potential support of the new interface...
Now when I get into fancier environments like LabVIEW or design-time drop-in development environments like Microsoft .NET, MFC stuff that seems to break.
You are mentioning in your answer to change all of the GUID. Is the whole paradigm of adapting an application based on available functionality dead, that a newer application could still use its basic functionality with the older version of a control? Maybe I didn’t catch the later wave that is: No point in adapting an application to run using old control version, it simply requires a specific control version. That would be reason M$ also came out with the ASSEMBLY thing.
To implement "method-missing"-semantics and such in C# 4.0, you have to implement IDynamicObject:
public interface IDynamicObject
{
MetaObject GetMetaObject(Expression parameter);
}
As far as I can figure out IDynamicObject is actually part of the DLR, so it is not new. But I have not been able to find much documentation on it.
There are some very simple example implementations out there (f.x. here and here), but could anyone point me to more complete implementations or some real documentation?
Especially, how exactly are you supposed to handle the "parameter"-parameter?
The short answer is that the MetaObject is what's responsible for actually generating the code that will be run at the call site. The mechanism that it uses for this is LINQ expression trees, which have been enhanced in the DLR. So instead of starting with an object, it starts with an expression that represents the object, and ultimately it's going to need to return an expression tree that describes the action to be taken.
When playing with this, please remember that the version of System.Core in the CTP was taken from a snapshot at the end of August. It doesn't correspond very cleanly to any particular beta of IronPython. A number of changes have been made to the DLR since then.
Also, for compatibility with the CLR v2 System.Core, releases of IronPython starting with either beta 4 or beta 5 now rename everything in that's in the System namespace to be in the Microsoft namespace instead.
If you want an end to end sample including source code, resulting in a dynamic object that stores value for arbitrary properties in a Dictionary then my post "A first look at Duck Typing in C# 4.0" could be right for you. I wrote that post to show how dynamic object can be cast to statically typed interfaces. It has a complete working implementation of a Duck that is a IDynamicObject and may acts like a IQuack.
If you need more information contact me on my blog and I will help you along, as good as I can.
I just blogged about how to do this here:
http://mikehadlow.blogspot.com/2008/10/dynamic-dispatch-in-c-40.html
Here is what I have figured out so far:
The Dynamic Language Runtime is currently maintained as part of the IronPython project. So that is the best place to go for information.
The easiest way to implement a class supporting IDynamicObject seems to be to derive from Microsoft.Scripting.Actions.Dynamic and override the relevant methods, for instance the Call-method to implement function call semantics. It looks like Microsoft.Scripting.Actions.Dynamic hasn't been included in the CTP, but the one from IronPython 2.0 looks like it will work.
I am still unclear on the exact meaning of the "parameter"-parameter, but it seems to provide context for the binding of the dynamic-object.
This presentation also provides a lot of information about the DLR:
Deep Dive: Dynamic Languages in Microsoft .NET by Jim Hugunin.