MSure v0.7 was just released. Check it out at the new website.

.NET Remoting är det som använts som kommunikationslager i ProcessIt! sedan start. Så är inte längre fallet; jag har nu kastat ut allt vad .NET Remoting heter (med undantaget för att kunna ladda assemblies [vad heter det på svenska?] i andra applikationsdomäner) och ersatt det med hederliga TCP/IP sockets.

Att använda .NET Remoting verkade från början vara en en bra idé, men nu ett halvt år senare så önskar jag att jag aldrig hade hört talats om det. Främsta skälet är att man inte har 100% kontroll över vad som händer, till skillnad från sockets där inget händer utan att man ber om det. Jag tycker att Microsoft har lyckats bra med hela .NET-platformen (i all fall version 2.0, jag har inte använt senare versioner) men .NET Remoting är en stor besvikelse. Visst, att kunna göra anrop via proxys till objekt som finns på andra datorer över ett nätverk är ju läckert men jösses vilken overhead det skapar i form av nätverkstrafik och minnes utnyttjande och så slött det är. Nej, tacka vet jag gamla hederliga sockets; de gör vad man ber dem om, inget annat.

Vill du diskutera detta inlägg? Gör då det i forumet!

De visa säger att en bild säger mer än tusen ord och det brukar stämma. Så istället för att beskriva hur den tidigare nämnda klienten kommer att se ut, så visar jag därför en bild istället.

Kanske inte ser så mycket ut för värden just nu, men det ger er en ide om var det är på väg. Som synes är det MDI (Multi Document Interface) som gäller - dvs flera vyer kan öppnas i programmet, t.ex. 1-Wire schema, temperaturgrafer mm.

Så vad har jag gjort de senaste två dagarna? Ritat den supersnygga gröna ikonen? Jajamensan! Nä, allvarligt talat så har jag spenderat min tid med att komma runt ett problem som bara måste lösas; multitrådning i en visuell applikation. En del av er kanske inte vet vad jag pratar om nu, men för er som vet så tänker jag fortsätta att pladdra (det är dessutom ett bra sätt för mig att bearbeta mina tankar!)

Som bekant ska applikationen kunna visa flera olika vyer samt presentera olika typer av data, samt hantera användarens klickningar osv. Eftersom det från kärnan kan komma information sporadiskt (nej, jag vill inte använda pollning - det är fegt! ) så måste applikationen hela tiden vara beredd på att hantera denna information och samtidigt inte “låsa sig”, dvs sluta svara på användarens kommandon - det finns inget mer frustrerande för en användare än en applikation som “hänger sig”, även om det bara handlar om en halv sekund. För att komma runt detta använder jag multitrådning. Detta innebär att alla bearbetningsprocesser körs i bakgrunden, medan användaren glatt kan klicka vidare.

Det låter ju inte så svårt, eller hur? Det är det inte heller, men nu blir det knepigare. När informationen bearbetats färdigt ska den presenteras för användaren i ett fönster eller på annat sätt. Det är detta steg som jag jobbat på de senaste dagarna - problemet är att det ramverk jag använder, Microsoft .NET, inte tillåter att man uppdaterar visuella komponenter från anda trådar än programmets huvudtråd (det går att ignorera denna begränsning, men det är *inte* en bra idé). Så vad kan man göra då?

Alernativ 1:

if( InvokeRequired ) {
visualComponent.BeginInvoke( new MethodInvoker( DoTheWork ) );
}
else {
DoTheWork();
}

Denna lösning funkar, men det blir en väldig massa extra kod - man använder ju fler än en metod per komponent….så nej, bättre lösning måste finnas.

Alternativ 2:
Skapa egna varianter av de komponenter man vill använda och utgå från det som finns genom arv. Denna lösning fungerar också, och jag har t.ex. använt den i Temperaturkoll. Tyvärr bygger den delvis på alternativ 1, så även detta ger en stor mängd extra kod….så nej, det måste finnas en ännu bättre lösning.

Alternativ 3:
Alla Windows program bygger på grundprincipen att det finns något som kallas meddelandekö (Engelska: message pump) i programmet. Så är det även då man använder .NET, fastän den inte är lika tydligt exponerad. Efter två dagars experimenterande har jag nu kommit fram till att det bästa sättet att få saker och ting att fungera, utan att skriva en massa onödig kod, är att utnyttja denna meddelande kö till att be programmetshuvudtråd att utföra de önskade kommandona med hjälp av en synkroniserad kö där den kan hämta den information som ska visas. Naturligt vis läggs ingen logik-hantering i detta då vi ju är i den så kallade vyn (se [url=http://en.wikipedia.org/wiki/Model-view-controller]Model-View-Controller[/url]), dvs i presentationslagret.

Mins du en gröna ikonen jag nämnde i början av detta inlägg? Den styrs enligt alternativ tre och är bevis på att mina design fungerar vilket, om jag får vara ärlig, känns skönt - jag vill ju implementera funktioner, inte lösa ett problem som jag tycker Microsoft borde ha tagit fram en lösning på redan vid designen av ramverket. Kanske de gjort det i senare versioner (3.0 & 3.5)?

Alternativ 4:
Vet du ett bättre sätt att göra detta? Snälla, berätta!

Har du läst allt ovanstående? Bra jobbat, kanske lärde du dig något

Skrev klart de viktigaste funktionerna i LSIHD44780LCDIIContainer idag, så nu finns det en fungerande klass för Louis Swart’s LCD driver i C#

Se https://sourceforge.net/projects/owdotnet

So, it’s been a few days since I last posted that I would stick to my own 1-Wire library and things have changed since then. I’ve put my project on hold to help out with the Open Source C# 1-Wire project initiated by Ralph Maas.

You can find the project here.

Another post in English, just to please the larger audience.

I just finished an interesting discussion with another developer, about starting an Open Source 1-Wire project to convert the existing Java 1-Wire classes provided by Dallas/Maxim to C#. We’ll see what this ends in, sounds promising.

Update: After having a look at the code that was provided (which is based on the alpha release of the “Pure C#”-code by Dallas), I’ve come to the conclusion that I’m going to stick to my own 1-Wire library for the time being. Although using the code-base from Dallas might give some benefits - it is the official C# library after all - I also see benefits of using my own implementation. The biggest advantage to use their code-base is obviously the device containers that comes with it; I’ll have to implement those I need in my library. On the other hand, there are very few devices for which I need support; it’s just temperature sensors (Family 0×10), switches (0×05) and a third party LCD driver.

Support for temperature sensors are already implemented and judging by the data sheet for DS2405, implementing support for that switch doesn’t look very hard. The same goes for the LCD driver. So, until someone convinces me otherwise, I will continue to develop my own library.

Oh, for those who wonders: I’ve not decided if I shall release my library as Open Source or not yet. I’m still thinking about it.

Here’s another post in english, to please the larger audience.

As the title suggests, I’m busying myself with 1-Wire mixed with C# again. I’m not sure if all this is good or bad idea, but it is fun, and that’s enough to keep me going

So, what’s this all about then? Well, almost a year ago - to the day actually - I expressed my disappointment in that Maxim/Dallas still hadn’t released their Pure C# 1-Wire library. They still haven’t, and they’re not giving any indication on when they will provide a finished library. The last time they said anything about this was on Nov 29th, 2007:

Brian Hindman:
Hi. We hope to come out with a OneWireLinkLayer dll compiled for .NET 2.0. The plan is to include it in the next revision of the 1-Wire SDK for Windows. Look for it at the end of the year. I’m afraid it won’t have any advanced features than what is available now. We have not ported over any 1-Wire Containers or MemoryBanks yet, as we have been short-staffed for quite some time. We hope to remedy this and get back on track soon.

In the latest release (currently 4.01) of their TMEX drivers they included a OneWireAPI.NET.dll, but it is Java-based, and as such it requires you to install the J# redistributable on all computes where you want to run the application in which you use the dll, and it also requires you to mix Java with C# in your application. Not a solution I’m very fond of.

What can be done about this? Well, you could wait for them to release their Pure C# 1-Wire libary, or you can do like me: write your own implementation in C#! Yes, you read that right - I am writing my own 1-Wire library, in C#. Below are some details (subject to change) about the library:

• Pure C#
• Uses the TMEX drivers
• Likely supports all port adapters, currently DS9490 and DS9097E have been tested.
• Device support:
  • Support for DS1920/DS18S20 is nearly complete.
  • Support for the LSD 1-Wire slave device by Louis Swart will be implemented
  • Support for any 1-Wire device can be implemented, provided that a specification is available.

Back to coding!