Temporal Flux and Mono:
To put it very simply, this combination Does Not Work. TF crashes on startup with the following error:
Unhandled Exception: System.EntryPointNotFoundException: GetCurrentThreadId
at (wrapper managed-to-native) WeifenLuo.WinFormsUI.Docking.NativeMethods:GetCurrentThreadId ()
at WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl+LocalWindowsHook.Install () [0x00000]
at WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl..ctor (WeifenLuo.WinFormsUI.Docking.DockPanel dockPanel) [0x00000]
at (wrapper remoting-invoke-with-check) WeifenLuo.WinFormsUI.Docking.DockPanel/FocusManagerImpl:.ctor (WeifenLuo.WinFormsUI.Docking.DockPanel)
at WeifenLuo.WinFormsUI.Docking.DockPanel..ctor () [0x00000]
at (wrapper remoting-invoke-with-check) WeifenLuo.WinFormsUI.Docking.DockPanel:.ctor ()
at Temporal_Flux.MDIForm.InitializeComponent () [0x00000]
at Temporal_Flux.MDIForm..ctor () [0x00000]
at (wrapper remoting-invoke-with-check) Temporal_Flux.MDIForm:.ctor ()
at Temporal_Flux.MDIForm.Main () [0x00000]
If I get some time over the next few days (which will only happen if the damned migraine goes away), I'll try siccing the Mono Migration Analyzer on TF and see if it can tell me a bit more about what's going on, since I don't need source for that.
I'm running on Linux with Mono 2.4 (latest release), but I wouldn't expect the results to be any better on a Mac. Anyway, I'm hoping that this will be a simple fix, because I can't expect you to undertake a complicated one for the sake of <5% of the potential hacking population. ;P
----------------------------------------------------
Okay, update. I ran TF through the Migration Analyzer, and it looks like there are three separate issues. The good news is that I think two of them are easy to resolve. The bad news is that I don't know what to do with the third one.
1. WeifenLuo.WinFormsUI.Docking.dll generated most of the significant errors...but judging from the name of the library and the information that MoMA regurgitated, you're only using this for window docking, right? And while docking may be a nice-to-have, it isn't a vital function of TF, so the easy fix for the problems here is to use runtime conditionals to deactivate the docking functionality when TF is running under Mono--see the relevant section of
http://www.mono-project.com/Guide:_Porting_Winforms_Applications .
2. The main TF executable generates a number of warnings about "void InitializeComponent () void Form.set_AutoScaleBaseSize (Size) Setting this is probably unintentional and can cause Forms to be improperly sized. See
http://www.mono-project.com/FAQ:_Winforms#My_forms_are_sized_improperly for details." The information at the end of the link indicates that it's 90% probable that these calls are unnecessary boilerplate added by your IDE and can be safely deleted.
3. And now we get to the one I don't know how to deal with, mostly because I don't have enough information. What's being flagged are two P/Invoke calls inside GGRLib.dll. They're both identical--calls to SendMessage(IntPtr, int, int, int) in user32.dll from void EditCell(int, int). I can't tell from the information available what these calls are doing--actually, I don't even know whether this library is your own, or if you have the source. If you do, and whatever these calls are doing isn't 100% vital, runtime conditionals are probably the way to go again, since there does not appear to be a managed-code replacement for SendMessage.
Caveat: I am not a C#/.NET programmer, nor do I play one on TV. I prefer Java as a general-purpose GUI-coding language, since it runs equally crappily on all platforms.
![](http://img179.imageshack.us/img179/369/iconalfador.gif)