Posts Tagged ‘Fragment Sync’

Miscellaneous Mono and Mono WinForms issues

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,

mono winforms linklabel rendering issue

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),

mono winforms linklabel rendering issue 2

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.

Let your app talk about itself

Fragment Sync has an automated update system called autobot. The system is used both for development and public releases (I should mentioned that automated updates to development copies of a networking app is a beautifully amazing thing). Updates are published to the autobot server using a simple publisher app, which puts the update package on the server and calls a server-side script to enter the patch details into a database. One annoyance with the publisher is that I would have to enter details (version, whether or not update is public, etc.) manually. This isn’t too bad, but on more than one occasion I’ve screwed things up by accidentally entering the wrong version or packaging an old executable.

I finally decided that the best way forward was to have the publisher automatically query the executable for information. You can embed this sort of information via. the application manifest, but using the manifest really didn’t cross my mind and I’m not a big fan of manifest files in general. In any case, what I did was have the executable take arguments and output the queried data to the console. This is a bit trickier than it sounds because, for whatever reason, a GUI app can’t send messages to a console without some hackery with the AttachConsole() Win32 function. (I’m dealing with C# and WinForms, but native Win32 GUI apps don’t have a default console either, so this isn’t a WinForms specific thing). The publisher redirected the standard output stream and read in the data that was pushed out.

This seems to have worked out nicely and has pushed me to think about other information an app can output about itself, lending to better communication between related apps.

Fragment Sync screenshots

These were posted a while back on the Fragment Sync site.

Fragment Sync main screen Fragment Sync sync mapping screen Fragment Sync sync screen Fragment Sync sync results screen