v2.1.43 b489: Initialization 'problem?'

Today I discovered an unusual and subtle bug, or problem, or behaviour (your choice, Torben ;)). I suspect it will only occur if you have a mAirList Remote Control interface for SOAP/Network set up, as I do here.

Note also that I have the config option for ‘Allow only one instance of mAirList’ set.

If you have the mAirListTag program already running (but not the active window), and then start the main mAirList program without clicking on the mAirListTag window again, mAirList will start and initialize without any problems.

If you have the mAirListTag program already running and then start the main mAirList program, then activate the mAirListTag window at any point during the initialization, mAirList will not start and will display an initialization error dialog which says that the SOAP/Network interface cannot be initialized because it is already in use (presumably by mAirListTag?). This happens even if you make a different window ‘active’ after ‘touching’ the mAirListTag window.

  1. I don’t know whther the ‘Allow only one instance’ switch should prevent mAirListTag and mAirList both being started at the same time, or not.

  2. The mAirList initialization behaviour is inconsistent: it should not vary depending on whether another window has been ‘touched’ or not during initialization!

Like I said, it’s unusual and subtle, but it seems very ‘wrong’ from where I’m sitting.


When you have set up a SOAP interface, it will also be active in mAirListTag, and thus mAirListTag occupies TCP port 9300. You cannot start mAirList then, or at least not with a SOAP interface enabled. This is independent from the “only one instance” option (which only affects multiple instances of the main program anyway).

I wonder why it does work when you keep the tagging window untouched.

;D I’m pleased it is not just me who’s baffled by that! I can only guess while a window is inactive, XP at some lower level ‘hides’ that program from whatever means you use to detect it; or at least, the program does not appear to be ‘bound’ to the port when other programs ‘enquire’ about the port.