semi/signal

Issue 1: Layout of anchored, non-visible control

I had a custom subcontrol anchored left and right within a parent control. The subcontrol was not visible and would only appear when I called a function to make it visible. The parent control had a default width and height, of course, but would be resized as necessary when placed on a form. With Mono, after being placed on a form, the anchoring seems to take effect based on the default dimensions of the control, not the dimensions of it in the form. This, of course, results in the subcontrol being an incorrect size and position.

I haven’t found a solution to this issue as yet.

Issue 2: Repaint after SuspendLayout/ResumeLayout

When adding a number of custom subcontrols (Dock=Top) to a Panel, I called SuspendLayout() before adding them, and called ResumeLayout() after. The height of the controls are adjusted right after they are added to automatically fit a word-wrapped block of text. On Mono, the Panel is never repainted (meaning the custom controls are never repainted either, and its text is not shown).

Calling Refresh() or Invalidate() after ResumeLayout() solves this issue.

An issue I discovered in Mono. When attempting to write a zero-length byte array (representing an empty string of UTF8 characters) to a HttpWebRequest stream, the stream is cut short at the position the write is being attempted; nothing after it gets written to the stream.

I’m not sure if this is specific to the HttpWebRequest stream. I encounter the issue on Mono 2.4 (under Ubuntu) and Mono 2.6.1 (under openSUSE).

After spending some time attempting to P/Invoke the stat() function, I discovered the wonderful Mono.Unix.Native namespace (found in the Mono.Posix assembly) which has some great stuff for lower-level Unix/Linux work.

Here’s what I did to pull a file’s inode number:

Unfortunately, the method mentioned in the Mono Technical FAQ, where you can check System.Environment.OSVersion.Platform for a value of 6 doesn’t work (as of Mono 2.6). I got the following code from this thread, which works well enough,

Despite some issues, my experience porting .NET C#/Winforms 2.0 code to a Linux system running Mono was surprisingly pleasant. Unfortunately, the same cannot be said for porting to OS X. Put simply, Mono Winforms on OS X sucks… it sucks bad… to the point where I question why it was even released.

The biggest and most apparent issues seems to be visibility and z-order issue. The image above is a form containing a few panels, however, only the panel containing the green header and the “sync with” label should the displayed. The others should be invisible (Control.Visible = false). Furthermore, making one control visible and another invisible or bringing a control to the front (Control.BringToFront()) such that it obscures others is a crapshoot; sometimes it’ll work correctly, other times you’ll see the correct control briefly before it disappears and your staring at a control that should be invisible or obscured.

Performance is atrocious. Winforms itself, even under .NET on Windows, is not a terribly high-performance windowing system, but it’s unbearable under OS X, to the point where you can see very prominent visual delays as events are processed and/or controls are being rendered.

Stability is awful. It’s not uncommon to reach a point where the application’s UI simply freezes up and no longer responds to events. Worse yet, disposal of Controls don’t seem to occur properly. I’ve noticed this on dynamically created controls, on a few occasions; clicking a control resulted in a crash because the control had already been disposed, but the control was still, incorrectly, being rendered in the UI and responding to events (hence the crash).

All of these problems seem to point to an issue with Mono’s per-windowing system driver for OS X. The Mono Project Roadmap indicates an upcoming Winforms update for OS X this September with the Mono 2.6 release, hopefully, it’ll address these (and I’m sure other) critical issues, so that Winforms can become truly cross-platform. As of right now, if your looking to use Mono Winforms as a solution for porting to OS X, you’ll likely only be able to pull off a port of the simplest of applications.

On a side note, Cocoa# looks like a pretty interesting project, but the website hasn’t been updated in months, so it’s possible the project is dead.

A few issues I stumbled across as I was working on porting Fragment Sync,

Issue #1: Explicit null second argument with ArrayList.BinarySearch
The second argument is optional and leaving it out should (I assume) be the same as passing null resulting in the method using the object’s CompareTo() method (implemented b/c of required IComparable interface). However, Mono threw an exception: System.ArgumentException : Comparer threw an exception …

Issue #2: LinkLabel rendering issues
You can see this in the screenshot from my previous post,

The linklabels at the bottom have their AutoSize properties set to false and their TextAlign properties set to MiddleCenter; the rendering issue is obvious (oddly enough, I noticed when a linklabel is disabled it renders correctly). Setting AutoSize to true and redoing some positioning, I got the following (note that a lot of other things have been fixed here as well focus on the menu at the bottom),

I’m still working on this and haven’t really found an optimal or pragmatic solution as yet.

Issue #3: No WYSIWYG for improperly anchored controls
Microsoft .Net Framework seems to be able to display a form as-is despite any sort of improper anchoring which would cause issues when resizing. Mono WinForms seems to behave a bit differently, and the position and layout of these controls are not identical to how they look in the designer. My guess would be that form are loaded differently between the 2 implementations.

Issue #4: Panel anchor issue
In Fragment Sync, there is a panel just above the bottom menu that appears and displays notifications. This panel is anchored to stay just above the bottom menu. For reasons I still haven’t figured out, this panel disappeared (I assumed behind the menu). I fought with this for quite a while, but finally surrendered and simply docked it to the bottom. I’m still not sure exactly what the issue was here and anchoring and docking seems to work fine in other forms and controls.

Issue #5: AutoScaleMode
This is something I never payed attention to, but the Visual Studio designer automatically sets AutoScaleMode to AutoScaleMode.Font for every form or user control created. This can very much screw up positioning and layout of elements, so I set it to AutoScaleMode.None for everything. Fragment Sync doesn’t really concern itself with scaling, so this might not be appropriate for every app. Not that this should be done within the designer, trying to change it after InitializeComponent() is called in the constructor seems to have no effect.

Issue #6: Form icon issue
I mentioned in the previous post about problem with Vista-compatible icons which have an embedded 256×256 png. Rather than muck around in the form designer code this can be addressed in the form constructor after the InitializeComponent() call, as the exception for the problematic icon is thrown when the form is shown not initialized. So simply set this.Icon = null; after InitializeComponent() or set this.Icon to a compatible icon.

Issue #7: Notify icon issue
This is caused by the same problem as above (Vista-compatible icons), but can’t be addressed after InitializeComponent() as the exception is thrown earlier, within InitializeComponent(). The easiest fix to just use another icon with the 256×256 bitmaps removed. You could also muck around in the form designer code and edit the offending line.

That’s it for now. I’m eager to do a OS X compile and run, which I’ll try to do within the week.

I’ve known about Mono since its inception, but a few months ago I really became interested as support for C# 2.0 and WinForms 2.0 was announced. I played around with some code and was pretty impressed at how easy it was to get stuff compiled and running. This weekend I made a concerted effort to tackle something more complex, getting Fragment Sync compiled and running. I’ve read you can simply use Mono with the managed executable and not have to deal with compiling source code, but Fragment Sync does quite a bit of interop with unmanaged code so that really wasn’t an option.

I first attempted to import all the source files into MonoDevelop (commenting out win32 specific stuff), but this proved problematic when it came to resources. I tried a ton of different things, but could not get MonoDevelop to properly compile in the app’s resources. I then read you can just open the Visual Studio solution with MonoDevelop; this proved to be effortless and resolved the compilation issue with resources.

After a successful compiled, I had some issues getting a window up. There was an issue loading the application icon. This seems to be an issue with using Vista-compatible icons (where the 256×256 sized bitmap, is an embedded png). I changed the icon to null for a few forms to resolve this; which involves the following line in the form designer code:

The final and most serious issue I encountered was with Fragment Sync’s Rijndael encryption code. You can find the issue described in detail here. Note the issue will pop up when using CryptoStream as well, since CryptoStream simply abstracts the calls to the underlying Transform methods of ICryptoTransform. The trick here is to always check that you can reuse the transform. With Microsoft’s implementation you can, with Mono you can’t. So you have to recreate the transform object.

With these issues resolved I could get things up and running.

Obviously things don’t look pretty, but I think this is a good starting point to work from to get Linux support for Fragment Sync.

I should mention I did consider using Gtk# and redoing the Fragment Sync user interfaces, but I found Gtk’s design methodology unbearable… let’s just say I’m not a fan of packing widgets into containers.