WildBill

Thanks for the compliments! If anyone can offer feedback I'd really appreciate it as it helps me make the program even better. I've posted version 0.8.4, which has a couple of fixes and improvements.

I've posted version 0.8.3, which will log more information if it catches an exception (which so far I haven't been able to reproduce). It also does a better job of smoothing text on title bars (there were some windows that it wasn't catching).

Well, at least that's some good news That's a real surprise that there was an exception on a BehaviorWndProcBefore message. That's definitely not what I expected. I'm putting in more logging so the message details will be logged, as well as the class name of the window that processed it. I'll see what I can reproduce here, but if I can't find out any more I'll see what else I can do and release the next version tomorrow.

I just posted version 0.8.2, which I'm hoping will give you better luck. I've made a ton of small changes to try to make it stable, and it's doing much better (for me, at least). I'm using a plain-vanilla Explorer from a fully patched SP4. I haven't tested repairing icons in Tweak UI, but I'll make sure to see what happens.

Yes, that's what I expected. I had made a small addition to the code that overrides standard controls when I added translucent taskbars. I'm able to sometimes recreate crashes here, and I'm trying (hard) to make it stable. At least now I have it narrowed down to a very small portion of code.

Would you mind checking to see if the crashes go away if overriding standard controls is turned off? I'm having trouble reproducing any crashes, but I have a hunch. I'll see what I can find at my end, but if we can narrow it down to a particular behavior that would help. I've also made some progress with title bars and have some preliminary text smoothing working (though there's a lot left to do).

No, I didn't do anything to popup menus, and they're being smoothed for me. I've posted version 0.8.1, which has had a lot of internal changes to try to make translucent taskbars stable. It's behaving very well for me, so I'm hoping to see translucent taskbar screenshots soon I've been feeling under the weather for a week, but the medicine is helping, at least somewhat. I'm going to just relax for the rest of the night. Enjoy...

Here is what I get with all translucency values set to 128, and mouseover set to 255. That said, I'm also seeing stability issues with Explorer on my laptop, though the desktop that I develop it on works much better. I still probably have some bugs to hunt down. I'm definitely seeing problems when changing translucency settings, which is implying to me that I need to look closely at what happens when I stop the translucent, alpha blending, or paint redirection behaviors. I'm feeling pretty lousy tonight (went to the doctor this afternoon), so I'll see what I can figure out tomorrow.

I've posted version 0.8.0, which I'm hoping will at least fix the crashing issues. I doubt that it will do anything on XP, but who knows. I'll have to test it on XP at some point. Please let me know if this helps.

Look at the post above yours.... I have to stress that this new feature is very alpha, and bugs should be expected. I had to write a TON of new code to make it work.

I've posted version 0.7.9, which adds translucent taskbar support for Windows 2000. There is a LOT of new and changed code, so I'd appreciate any bug reports, but for me it's working well. NT4 doesn't support layered windows so this feature won't work on NT4, but I've tested it on NT4 to make sure that I didn't break anything. I have no idea what will happen on XP, but a report would be interesting to know. Enjoy...

That's very strange. What font is selected? Is it just random text that you typed? As a side note, the next version of SmoothText is coming along very nicely. I have translucent taskbars working, though it's not 100% complete yet (I have to put in one more piece of code so it can redraw properly when you move or resize the taskbar). Otherwise, it's pretty awesome, though I've had to write a lot of code and overhaul the architecture yet again to get the flexibility and simplicity I needed. Lots of little i's to dot and t's to cross (including making sure that I didn't break NT4 compatibility), but otherwise I guarantee that Win2k users will love this new feature. (And in case anyone is wondering, there WILL be a skinning engine at some point. Putting in all these features first is setting up for a skinning engine quite nicely. I've had some wild ideas forming that should make for a pretty awesome experience when everything is done).

Just a quick update: it took me a while to find the incorrect parameter I was setting for UpdateLayeredWindow, but I finally have it working. I still need to make a lot of refinements, but I have overall taskbar alpha with different alpha values for the Start button and system tray. There's finally light at the end of the tunnel, now, though.

For the time being, I'm keeping everything combined, but I came up with the small, Behavior-based architecture so features can be tested individually as well as potentially broken up/combined in different ways. As far as XP goes, one OS at a time. Testing on different OS'es is hard, LOL! Tihiy, sorry for taking so long to reply. What do you have in mind? It would be pretty easy for me to break out the global text-smoothing stuff out into a separate DLL. Maybe you could then add it to the Win98 Revolutions Pack? Let me know what you think would work. Anyhow, the current SmoothText status (releasable soon, I hope): - WinRAR bug fixed (was a weird bug with Static controls) - Fixed several threading issues. - Glitches with button controls seem to be fixed. - Simple taskbar translucency is working (where you set the translucency for the entire taskbar). I don't think this is all that great a feature yet, so I'm now looking at trying to have per-pixel alpha blending (which I think is possible, but I'm still trying to work out the details in my head). - Quite a few internal improvements, prepping for future stuff.

I'm glad you like it. One of the things that's been nagging me is whether people are actually using it, or at least enough to justify all the work put into it. I know that Win2k will reach EOL in July, 2010, and I'm wondering what life will be like, then...will people be porting security fixes to it so I/we can continue using it, or will we be forced to XP? I hope this won't be all for nothing, because Win2k is a great, great OS. There are lots of things that I'd like to give SmoothText, but I don't know how far I'll be able to get. Here's a list of what's been on my mind: - NT4 support: I need probably another day of fiddling with it to get it up to current Win2k levels. I think there's just an issue with menu item width and then it will be "there". - More Win2k "extras": if anyone has been looking at the code, you might see a stub class called something like TLayeredBehavior. I'd like to take a stab at "proper" layered taskbars, where I have control over translucency of various parts, with decent speed when things are moved under it. I have a lot of code in my experimental TClock3 that should be very useful for it. - Taskbar skinning. One reason I haven't worked further on TClock3 is because my implementation is just a bad design -- I really jumped into it without properly designing it. I've been designing a skinning subsystem in the back of my mind for a while, and it should work well as one of SmoothText's "behaviors" that can be turned on or off. - Full skinning. Just an extension of the above, really. - API extensions. I really have no idea how to do this, and if it's really appropriate as part of SmoothText, so I might break that out into a separate (but similar) program (or I might not do it at all). The idea is to be able to extend the Windows API *without* having to change any files. I know how to extend via dynamic loading, that is, when applications call GetProcAddress (because I can override it just like I override text API calls), but I don't know how to override the PE loader so that Import Address Table entries can be added, fixed-up, whatever you might call it when an EXE or DLL is loaded. That might be something someone else has to take up, but I wanted to throw the idea out there. There are a lot of unknowns around layered windows for me, so trying it with taskbars will be the first baby step. I'd also like to implement title bar text smoothing without skinning, that is, mimicking current behavior, and that will probably be the first stab before I try skinning it. At any rate, a lot of the skinning code will be coming in some form from TClock3, and some of it has already been very useful (when SmoothText overrides standard controls it *is* skinning them, albeit by a different method). It should definitely go quicker than TClock3 development has since a lot of it has been already written. None of you have seen the TClock3 that I have, which skins most everything, supports animations, etc. It's too bad it's such a hack and is so unstable. I want the SmoothText version to be done "right", with a proper editor that can show what it will look like. It's the sort of thing I have to take one small step at a time, but I've already had a lot of sleepless nights when my mind just wouldn't turn off and insisted on designing parts of it.

I've posted version 0.7.8, which fixes a lot of issues on NT4. NT4 behavior is now very close to Win2k, with a few minor exceptions (NT4 users need to carefully select how MS Sans Serif, System, and MS Shell Dlg fonts are substituted -- I'm using Verdana, which comes with it). I'll have to look into the mIRC bug. I suspect what the culprit might be, but I'll have to investigate (I really thought I had squashed that particular bug, but perhaps I missed something). I have some bad news for Win98 users: the Win9x architecture might not allow SmoothText to work. SmoothText relies on the fact that when I overwrite code from a shared DLL, a local copy is made (copy-on-write). Win9x doesn't support this. It *might* be possible to use a different architecture where I make a shared DLL that I can trigger to change other shared DLL's, but I have no idea how to do this. I'll leave Win98 support in for now because there are other SmoothText features that do work (and others I have planned), but system-wide subpixel-antialiasing might not be possible (at least, not without help from people who are more knowledgeable than I am in some areas).

I've posted version 0.7.7, which I've verified works under NT4 (gah...I had no idea installing NT4 would be such a PITA. I have a whole new appreciation for Win2k, now). Overriding standard controls doesn't work right, but general font smoothing works just fine.

I've seen that, too. My guess is that it has to do with Windows' internal hinting, which is something that I can't control. It's definitely doing something to the x-height, and there isn't a setting for that.

I still haven't been able to reproduce it. I'm using version 2009.2, and everything looks great. What version are you using?

Posted version 0.7.6, with a rather important bugfix.

One more quick update: version 0.7.5. It adds a little more flexibility into configuring how SmoothText calculates what the font width should be. At this point it's hard to imagine adding much more font configuration without confusing people

Version 0.7.4 is up, with lots of fixes and goodies. I'd be interested to see if any font-width issues are now gone as a result. By the way, has anyone tried this on NT4 yet? I tried it on my installation of FreeCommander and both columns are being smoothed, by the way.

Wold this help? IconViewer 1.4 I originally wrote it to remove the alpha-blending from icons so they wouldn't have the black halos on Win2k, but perhaps you could use the part that loads the icon files.

I've posted version 0.7.3, which fixes the FreeCommander menu bug. It also has some other changes (hint: NT4 users out there should try this one). Enjoy...

Thanks a lot for the feedback. At least now I have some things to work on There's a reason why I don't force character placement to match the original spacing. SmoothText is overriding four API drawing functions (ANSI and Unicode versions of each:) TextOut ExtTextOut DrawState GrayString My TextOut implementation simply calls ExtTextOut, since ExtTextOut lets me force character placement. My DrawState and GrayString implementations, on the other hand, call the original API routines but with different parameters. I could do the same thing with DrawState and GrayString that I do with TextOut, that is, call ExtTextOut, and then change my ExtTextOut code to force character placement to exactly match the character placement of the original font. However, I have a reason not to: I have no control over how the glyphs are drawn. If a glyph for the "wide" font is too wide for the forced cell width you'll see characters running into each other. On the other hand, if it's too narrow, you'll see odd spacing between characters. I can only control the overall width of the font, and there's an algorithm that tries to come close, but ultimately Windows' hinting code has the final say on what a character will look like. There are also kerning issues to consider. I suppose I could make it an option, with no guarantee on visual quality (another possibility is to make it an option and also to create an option that lets people tweak the font-width algorithm).