I've tested plugin under blackbox. Plugin can be loaded in slit, but loading it in BBI causes blackbox to crush.
Here is a part of BB log. Maybe it will be usefull:

I'll dig a little deeper, see what I can find. Thanks for the heads up!

Thanks to noccy we figured out what was going on with LangDis. Get the v1.2 DLL in the original post here. I've tested under BBLean 1.16 and noccy tested under bbClean. Should work under bbLean_mod as well.

For the programmer types out there, here's what happened. I was reporting TRUE (1) on beginPluginEx which actually means there was an error. So the core thought the plugin did not load and apparently released the plugin's memory after I had done all initialization including sending the BB_REGISTERMESSAGE. In addition because the plugin had actually loaded, I did not delete the class instance that I was using. I was registered for the hook messages include BB_ACTIVATE, BB_REDRAW, etc. so when the core tried to send up a messagebox it also signalled to my now released winproc (via post message) that the window was changing. Can we see this going downhill?

Anyway, all fixed, thanks noccy for helping me knock this out!

It works!
I noticed, that slit is no needed now. But how can I change plugin' position, when it is not in slit?

And some downsides:
1. Terrible BIG (about 16-18 pt) font, if plugin is in slit or in BBI. I dont know, how it can be fixed.
2. It is impossible to view current keyboard layout, if switching with Ctrl+Shift or other default combinations. Plugin needs window reactivation to refresh the information in this case.

TNX for plugin!

You can't yet, one of the reasons that even if you do load it outside the slit, you shouldn't


Uses the style information returned from the core (specificly returned by GetStyleSettingPtr). Uses toolbar.windowlabel or toolbar (depending on whether it's slitted or on it's own.)



Hmm... Will have to see what can be done about that. To my knowledge the notification is only sent to the active window (which is why the plugin doesn't get the message.) But I'll see what I can find. My only recommendantion would be not to use the default key combinations and instead bind them as hot keys to the supplied broams.

hm... In my style font "snap" defined for all elements. But look at this screenshot:


And there is no such font defined nor in windows' theme settings nor in "global fonts" settings.

Hmm.. Seems to be working for me under BBLean 1.16..



The ENU in the menu is obviously hard coded

No problem! Crashing blackbox is twice as fun when you're doing it with someone

It looks allready fine, when is not in slit. Problem appears only when I load plugin in slit or BBI.

Ah. Okay, I think I know the problem then Thanks for the heads up!

Update for 1.4
Checks to make sure there is a font, if not requests SN_TOOLBAR which should always have a font

Download at original post

Once more little problem:
I have turned off default key combinations. Now I use Bro@ms via bbKeys to change layout. But plugin not always refresh info. About every 15th switch stays unnoticed by plugin. The next switch returns plugin to it's normal work.

And another interesting thing: when I'm using bbKeyHook and scancodes of Ctrl and Shift to switch layout, plugin ignores the first switch and displays previous to current layout (need to say, I have 3 layouts: ENU, RUS, UKR). For example if layout is Ukrainian, langDis displays "RUS", if - English, langDis displays "UKR" and so on. It lasts till the next "freeze" or reactivation of window.

It's all right with fonts now!

Thank you!

So are these the same problem or two seperate ones? I'm thinking they are seperate, and I think I might have a way around the second one. The first one is likely due to delay between the message being sent and when the application processes it. There's no return for it though (according to the documentation it should always be a PostMessage, meaning you don't wait for it.)

I'll try a couple things though and see how they work.