Januari 2012: Een foto van Dennis gemaakt op de peuterspeelzaal. Hij heeft het altijd naar zijn zin op de peuterspeelzaal.

Mocht iemand nog de behoefte hebben om muziekbestanden van Magic Music Module Professional in te lezen, bijvoorbeeld om ze om te zetten naar MIDI-bestanden, dan is dit document handig om te hebben.

Klik hier om het document te downloaden.

When the mobile device has a barcode reader, then when a barcode is scanned, this barcode is offered to the application as if it was typed on a keyboard. And typically a key press for the enter key is added after the barcode.

But what happens if the user accidently moved the focus from a text box to a button? If the user then scans a barcode, the key presses for the barcode are ignored, but the key press for the enter will cause a button click!

It turns out that preventing this button click is difficult in Compact Framework.

I finally found a solution in the article “SubClassing a Control Using Native Callbacks” at codeproject.com. Compact Framework offer the possibility for native code (like the Button class) to call managed code using a callback delegate. The article describes how to implement a callback delegate that is called when the mouse button is pressed or released.

The solution I came up with is to create a subclass of Button. When the mouse button is pressed a flag is set. The method OnClick() only handles the click if the flag is set and then clears the flag.

One minor problem was that pressing enter on the mobile device actually sent two mouse press events. The second event always has wparam = 0 and lparam = 0. When such an event is received I also clear the flag so that the following call to OnClick() does not handle the click.

Now I discovered UNetbootin. This tool copies a Linux distribution to a USB stick and makes it bootable. It can even download any of the popular distributions for you.

UNetbootin is available for Linux, Windows and Mac OS X.

Technologisch gezien kunnen we nu ontzettend veel. Wie begin twintigste eeuw had gezegd dat binnen honderd jaar een mens op de maan zou lopen werd voor gek verklaard. Inmiddels is het al weer veertig jaar sinds de eerste mens op de maan is geweest.

Ook niet voor te stellen aan het begin van de twintigste eeuw was het Internet. Het Internet heeft zich sinds de jaren negentig sterk ontwikkeld. Het Internet wordt steeds vaker gebruikt om bestaande media als radio, TV en kranten aan te vullen of zelfs te vervangen.

Maar zijn al deze ontwikkelingen nou allemaal even wenselijk? Mensen die mij al langer kennen, zullen de volgende uitspraak van mij inmiddels ook kennen: Leuk dat het kan, maar daar zit ik niet op te wachten.

Neem nou eens het bericht Techniek onderzocht om voedingsinfo op gsm te lezen dat op 3 juli te lezen was op de nieuwspagina nu.nl. In dit bericht oppert Herman Koëter van de Orange House Partnership om voedingsinformatie van allerlei producten te tonen op de mobiele telefoon. Als een klant in de winkel voedingsinformatie van een potje pindakaas wil krijgen hoeft hij niet het etiket te lezen, maar moet hij zijn mobieltje richten op de streepjescode van het potje. Vervolgens verschijnt de voedingsinformatie op zijn mobieltje.

Het is leuk dat dit technisch mogelijk is, maar wie zit hier nou op te wachten? Veel consumenten doen slechs eens per week boodschappen. Ze kopen dan altijd hetzelfde merk pindakaas, frisdrank, melk enzovoort. Ze gaan echt niet iedere week de voedingsinformatie van deze producten bekijken op hun mobieltje.

Naast tonen van productinformatie stelt Koëter ook voor dat voor mensen met overgewicht een “rood alarm” krijgen voor slechte producten. Dit is echter een onpraktisch idee. Binnen een gezin is het meestal dezelfde persoon die de boodschappen doet voor het gehele gezin. Het mobieltje kan moeilijk bepalen voor welk gezinslid het potje pindakaas bedoeld is en of pindakaas ongezond is voor dat gezinslid. En geeft het systeem ook een alarm als iemand in het gezin allergisch is voor pinda’s?

Mensen die echt op hun voeding moeten letten vanwege een dieet verdiepen zich in de materie. Dit doen ze niet in de winkel, maar thuis. Verder doen ze dat niet met hun mobieltje maar met boeken of webpagina’s. Er zijn al talloze boeken en webpagina’s beschikbaar met gedetailleerde voedingsinformatie van alle producten. Dus de mensen op wie het nieuwe systeem gericht is kunnen prima uit de voeten met de huidige informatiebronnen.

Tot slot vrees ik dat een dergelijk complex systeem zeer duur is om te ontwikkelen. Ten eerste zijn er techinsche uitdagingen om een mobieltje een streepjescode te laten lezen en informatie op te laten zoeken op Internet. Ten tweede zal het een gigantische klus zijn om alle voedselproducenten ter wereld hun etiketinformatie digitaal te laten aanleveren.

Het moge duidelijk zijn dat het voorgestelde systeem moeilijk en duur is om te realiseren. Verder is het een technologische oplossing voor een probleem dat al opgelost is met eenvoudigere middelen. Voor mij geldt dus: leuk dat het kan, maar daar zit ik niet op te wachten.

Dennis heeft pepernoten gesnoept. Op deze foto kijkt hij wat beteuterd. Wellicht wil hij nog meer pepernoten?

username ALL=(ALL) NOPASSWD: ALL

Save and that’s it.

export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun-1.5.0.11

For details see the bug in the Eclipse bug database.

Introduction

Do you get irritated when you receive e-mails containing HTML for a fancy layout? Or when someone sends you by e-mail a Word document containing a few lines of text (that could easily have been sent as a text-only message)? Or when a company sends its weekly newsletter in Word format and you are using Linux and may not have access to Microsoft Word at all?

If so, then you are suffering from the incompatibility problem. You might feel a bit relieved to know you are not the only one suffering from this problem.

If not, then it is likely your computer runs Microsoft Windows, your word processor is called Microsoft Word and you use Microsoft Outlook as a mail client. And probably you are viewing this web page in Microsoft Internet Explorer.

The incompatibility problem

I define the incompatibility problem as the problem that data created with one application can not be used by another application without problems. Examples of data are text documents, spreadsheets, web pages, e-mails, music and pictures.

Unfortunately, there are many examples of this problem:

• documents created in Microsoft Word look slightly different when opened in Open Office Writer
• e-mails formatted in HTML become illegible when opened in a text-only mail client
• web pages specifically designed for Internet Explorer look very different in other browsers (e.g., Mozilla Firefox, Opera and Konqueror)
• even worse: some web pages designed for Internet Explorer are completely unaccessible in other browsers (e.g., because Visual Basic scripts are used)

Solution 1: standardise the software

One way to prevent the incompatibility problem is by using one application per type of data, so that there is no ‘other application’ that has problems with that type of data.

This solution is very popular in companies. Especially large companies tend to choose one word processor, one spreadsheet, one mail client, etc. All of their employees must use those applications, which become a company-wide standard.

To avoid the incompatibility problem from occurring, companies have to forbid their employees to use other tools than the ones offered by the company.

But is it wise to solve the incompatibility problem by standardising the applications? This solution has its disadvantages:

First of all, other companies may have standardised another set of applications. The incompatibility problem still exists between companies!

The incompatibility problem between companies could be solved by standardising the applications worldwidely. For a big part this is the case anno 2004: Most people use Microsoft Windows as operating system, Microsoft Word as word processor and Microsoft Internet Explorer as web browser. This brings me to the second disadvantage…

If one becomes dependent on a certain type of application, the producer of that application can ask (even more) ridiculous amounts of money for this application. Further, the producer can get away with delivering an application with serious bugs and security leaks! Switching to another application is hard, because of the incompatibility problem! (Wasn’t that exactly the problem that one tried to solve? How ironical…)

Solution 2: standardise the data

Another way to prevent the incompatibility problem is by standardising the data instead of the applications that use the data.

In many domains non-proprietary, open standards have been defined for data. For example:

• for sharing documents, that do not need to be edited anymore, the PDF format is well-suited. It replaces the older postscript format that is popular in the Unix domain.
• for offering hypertext documents (e.g., via the Internet) the HTML standard was designed. The document you are reading now is an HTML file.
• for sharing pictures the GIF, PNG and JPG formats are very popular. Computers, digital cameras, DVD players, mobile phones and many more devices can handle these formats. This goes much further than just sharing between applications!
• for sharing music, the MP3 file format and, more recently also the Ogg file format, are widely used. Computers, CD/DVD players, car radios, portable MP3 players and many more devices can handle these formats. Again, this goes much further than just sharing between applications!

The XML standard makes it relatively easy to define new standards for data. The ability to share files between applications, when using XML, comes almost for free! Many new applications and tools (especially from the free-software domain) use the XML standard. For example:

• Ant (Java’s version of the ‘make’ tool) uses well-defined build files, based on XML, which are far better readable than the traditional makefiles.
• Gnumeric (a spreadsheet for Linux) stores its data in compressed XML files. (By the way, Gnumeric handles Excel sheets quite well!)
• OpenOffice (an office suite comparable to Microsoft Office) stores its data as compressed XML files.
• The bookkeeping application GnuCash stores data as XML files.

Note that standardising data does not suffer the problems mentioned for solution 1.

Conclusion

I hope I have convinced the reader that the best way to solve and prevent the incompatibility problem is by standarding data (file format) and the way data is exchanged (protocols) instead of standardising applications.