RE: [rdnzl-devel] Generic types and default thread apartment
Hi!
On Thu, 14 Sep 2006 10:25:07 +0200, "Goffioul Michael" <goffioul@imec.be> wrote:
1) does RDNZL support generic types? If yes, how do I create such an object using RDNZL syntax?
This is something that was introduced in .NET 2.0, right? No, no support yet, I haven't even thought about it. You're welcome to supply patches, I probably won't find the time to look into this in the near future.
I had a look and you don't event need a patch :-) Generic objects can be created on the fly by specifying the parameter type between brackets, like: (new "System.Collections.Generic.List`1[System.String]") If you have 2 type parameters, then use "2" instead of "1" and separate types with a comma. Of course, RDNZL could provide a wrapper API to make the syntax simpler, but it's not mandatory.
2) from a GUI perpective, it would be better to set the apartment state of the RDNZL.dll assembly to STA, otherwise various components do not work properly; is there a reason to not do it?
I have to admit that I don't even know what the apartment state of a DLL is. Could you tell me what it's for and how I change it? And what doesn't work if the state is as it is now?
I'm not an expert neither, but I think this is related to Interop and COM. In Single-Thread-Apartment (STA), all COM messages are processed in the same thread, while in Multi-Thread-Apartment (MTA, the default in .NET if you don't specify anything) COM objects can be accessed by multiple concurrent threads. In GUI, even in multithread application, the GUI (message loop) must run in a single thread, I guess that's why STA is preferable in Windows Forms application (In Visual Studio 2005, when you use the wizard to start a GUI application, it set the threading model to STA by default). Now about the effects, I think that some .NET components are simply based on existing COM components (which is hidden to the user). At least I had problems with common dialogs: the directory dialog and the file dialog. When using MTA, the directory selection dialog does not show the directory tree, and the file dialog does not list items correctly (for instance, "My Computer" is empty, or the dialog does not update itself when you change the filter). Try this (tried with .NET 2): (rdnzl:enable-rdnzl-syntax) (rdnzl:import-types "System.Windows.Forms" "FolderBrowserDialog") (setq dlg (rdnzl:new "System.Windows.Forms.FolderBrowserDialog")) [ShowDialog dlg] This problem was the cause that made me recompile RDNZL-cpp under VS2005. If you look into StdAfx.cpp, you'll see how I changed the apartment state, but I don't know if it would work under VC.NET-2003. Michael.
On Thu, 14 Sep 2006 11:09:11 +0200, "Goffioul Michael" <goffioul@imec.be> wrote:
I had a look and you don't event need a patch :-) Generic objects can be created on the fly by specifying the parameter type between brackets, like:
(new "System.Collections.Generic.List`1[System.String]")
If you have 2 type parameters, then use "2" instead of "1" and separate types with a comma.
Ah, good... :)
Of course, RDNZL could provide a wrapper API to make the syntax simpler, but it's not mandatory.
Yeah, I'll keep that in mind for a future release.
I'm not an expert neither, but I think this is related to Interop and COM. In Single-Thread-Apartment (STA), all COM messages are processed in the same thread, while in Multi-Thread-Apartment (MTA, the default in .NET if you don't specify anything) COM objects can be accessed by multiple concurrent threads. In GUI, even in multithread application, the GUI (message loop) must run in a single thread, I guess that's why STA is preferable in Windows Forms application (In Visual Studio 2005, when you use the wizard to start a GUI application, it set the threading model to STA by default).
Now about the effects, I think that some .NET components are simply based on existing COM components (which is hidden to the user). At least I had problems with common dialogs: the directory dialog and the file dialog. When using MTA, the directory selection dialog does not show the directory tree, and the file dialog does not list items correctly (for instance, "My Computer" is empty, or the dialog does not update itself when you change the filter).
Try this (tried with .NET 2):
(rdnzl:enable-rdnzl-syntax) (rdnzl:import-types "System.Windows.Forms" "FolderBrowserDialog") (setq dlg (rdnzl:new "System.Windows.Forms.FolderBrowserDialog")) [ShowDialog dlg]
This problem was the cause that made me recompile RDNZL-cpp under VS2005. If you look into StdAfx.cpp, you'll see how I changed the apartment state, but I don't know if it would work under VC.NET-2003.
So, do I understand correctly that you already experienced these problems with the DLL compiled with VS2003? Thanks, Edi.
On Thu, 14 Sep 2006 11:09:11 +0200, "Goffioul Michael" <goffioul@imec.be> wrote:
If you look into StdAfx.cpp, you'll see how I changed the apartment state, but I don't know if it would work under VC.NET-2003.
OK, I just copied that and it seems to work fine for the old version as well. I could also reproduce the FolderBrowserDialog test case you described. New version (C++ code and Lisp tarball with the new DLL) are online. Thanks, Edi.
On Thu, 14 Sep 2006 11:09:11 +0200, "Goffioul Michael" <goffioul@imec.be> wrote:
I'm not an expert neither, but I think this is related to Interop and COM. In Single-Thread-Apartment (STA), all COM messages are processed in the same thread, while in Multi-Thread-Apartment (MTA, the default in .NET if you don't specify anything) COM objects can be accessed by multiple concurrent threads. In GUI, even in multithread application, the GUI (message loop) must run in a single thread, I guess that's why STA is preferable in Windows Forms application (In Visual Studio 2005, when you use the wizard to start a GUI application, it set the threading model to STA by default).
Just FYI - this change (RDNZL 0.10.6) also resolves the old issue mentioned here http://common-lisp.net/pipermail/rdnzl-devel/2005-December/000041.html for AllegroCL. For LispWorks 4.4.6 you can find a workaround in the mailing list, for LispWorks 5.0 and Corman Lisp you don't need a fix.
participants (2)
-
Edi Weitz -
Goffioul Michael