Brother MFC-J435W Startup

I was trying to scan quite a big stack of documents in Brother’s MFC-J435W multifunctional device and I was hitting some driver error after couple of pages. What made whole affair annoying wasn’t the error. It was the fact that scanner would continue pulling pages. That made it impossible to easily continue scanning of nonfailed batch.

Proper behavior is to stop pulling new pages in case of an error. No programmer (and let’s face it, firmware and driver programmers are ones deciding about this) would think to continue printing after paper jam. Why would they think that pulling paper after scan has failed is any different? If something fails, stop the feeder!

Since printer was on for a long time I figured that quick reboot would make it work properly. First I was asked some stupid question about losing all fax data even though I haven’t used fax functionality on it. If you are going to stop user action with question, first check whether question is even necessary!

And, guess what, feeder starts working upon startup and picks each and every one of your papers through. For what purpose is this? And don’t tell me it is to verify feeder. Of what possible use is information that feeder is not working during startup?

Whether feeder is functional or not matters only when user attempts to use it. At that time you can do quick self-test if you really must. However, you might as well actually use feeder and scan pages. If you retrieve data and move pages through, it works. Yep, you can do self-test and actual work at the same time.

I find current behavior very annoying because somebody had to write code in order to make product worse. If they were lazy and made no effort to write verification procedure and include it in startup, everything would be fine.

Writing code is not hard. Knowing when to stop is.

PS: While I use Brother’s device as an example, most other devices make the same unnecessary check.

Dealing With Namespaces in XmlWriter

XmlTextWriter comes in really handy when all you need is serial XML output. With simple commands you can create well formed and nicely indented document:

using (var xw = new XmlTextWriter(stream)) {
    xw.WriteStartDocument(true);
    xw.Formatting = Formatting.Indented;
	xw.WriteStartElement("abc:Group");
    xw.WriteAttributeString("xmlns:abc", "http://www.example.com/something/");
    xw.WriteStartElement("abc:Element");
    ...
}

However, XmlTextWriter has limited formatting capabilities. If you want LF instead of Windows-style CRLF you will need to use something else. For me that “something else” was XmlWellFormedWriter.

To get XmlWellFormedWriter you just ask XmlWriter to create one for you. Direct replacement code would look close to this:

var settings = new XmlWriterSettings() {
	Encoding = new UTF8Encoding(false),
	Indent = true,
	IndentChars = "    ",
	NewLineChars = "\n"
};
using (var xw = XmlWriter.Create(stream, settings)) {
    xw.WriteStartDocument(true);
	xw.WriteStartElement("abc:Group");
    xw.WriteAttributeString("xmlns:abc", "http://www.example.com/something/");
    xw.WriteStartElement("abc:Element");
    ...
}

And, lo and behold, this code causes ArgumentException (Invalid name character in 'abc:Group'. The ':' character, hexadecimal value 0x3A, cannot be included in a name.). With XmlWellFormedWriter there is no cheating and manually creating XML namespaces. You can still use them, but code will look a bit different:

using (var xw = XmlWriter.Create(stream, settings)) {
    xw.WriteStartDocument(true);
    xw.WriteStartElement("abc", "Group", "http://www.example.com/something/");
    xw.WriteStartElement("abc", "Element", null);
    ...
}

PS: Yes, there is no guarantee that XmlWriter.Create will give you XmlWellFormedWriter. However, it will surely give you something close enough for this code to work.

Taking Over Standard Output

As I was running Java process from .NET program, occassionaly I would notice that program would got stuck. Long story short, I traced my issue to following exception:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
    ...
    at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230)
    at java.awt.Component.processFocusEvent(Component.java:6397)
    ...
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:139)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)

This exception is not something that would crash application. If I ran Java program from command prompt, exception would be printed out and program would continue.

What ended up being problem was fact that I was reading standard output from my .NET application only upon application exit. If Java application started printing too much stuff before that point, it would fill up the buffer and wait for somebody to read that data. Since there was nobody reading that data, it would wait indifinetely.

There is really easy way around it. Trick is to consume data as soon as it arrives with help of BeginOutputReadLine and OutputDataReceived handler:

process.StartInfo.RedirectStandardOutput = true;
process.OutputDataReceived += process_DataReceived;

process.Start();
process.BeginOutputReadLine();

if (process.HasExited) {
    //do something with collected data
}

private static void process_DataReceived(object sender, DataReceivedEventArgs e) {
    //store data somewhere (e.g. global StringBuilder)
}

OS X Trash

As a developer I find it useful to show hidden files. And every time I borrow my USB to someone with OS X I find two new hidden folders: .Trashes and .Spotlight-V100. While these folders are important for OS X functioning (equivalents of Recycle bin and File Indexer) they are very annoying to see on USB. Only if there was a way to these folders more hidden…

Well, you can always set system attribute. While Windows don’t allow you to manage it through interface, this attribute is nothing special. Once you go to Command prompt, commands are really easy (assuming G: drive):

G:
ATTRIB +s +h .Spotlight-V100
ATTRIB +s +h .Trashes

Yes, folders will still be there but far from an eye. :)

P.S.: Just deleting these folders will not really work. They just re-appear next time USB goes to visit OS X.

P.P.S.: This “fix” will not work if you uncheck Hide protected operating system files option.

P.P.P.S.: And shame you OS X for not setting this attribute yourself.

OSH Park Just Got Bigger

Last few years it got really easy to have your PCB manufactured in small quantities. All manufacturers shared similar price but each had its own peculiarities.

I find it very sad that one such manufacturer, BatchPCB, is closing its doors. It is not that I used them often. It is not that they were anything special. It is not even that they were cheap(er). It is just that I liked the choice.

Good news is that they were taken over by OSH Park. BatchPCB users can expect lower prices on smaller than 20 cm2 boards, they can expect ENIG finish (aka “gold”), and they can expect free shipping within USA.

Dream purple.