WildBill

Thanks for the quick reply. I'll take a look at the logs. Mine is a slipstreamed SP2 that's been patched. EDIT: Unfortunately I don't think the logs will help. I might have to wait until you get another FastMM error log. I suspect that something in memory is being corrupted and that is causing all the exceptions that SmoothText is catching.

Tripo, For each image you want to use, you need an [iMAGEx] section that points to it. It doesn't matter how many "frames" are in the image, it's just a reference to an image file. Then, for each component you want to display (and each state it might be in), you need a [COMPONENTx] entry. So for instance, in the sample .ini file there are three [COMPONENT] entries for the start button, but each references a different state (normal, hot, and pressed). In this example the frames for those states all happen to be in the same image, so the three start button [COMPONENT] entries has the same image ID in them (Image=StartButton) but have different frame indices (0, 1, and 2, respectively). I did it this way so you don't have to be forced to have component frames organized in any particular fashion; they could be arranged left-to-right, right-to-left, or in a two-dimensional grid, or in separate files, and in any order. As long as you have the right Image=, StartingFrame=, and EndingFrame= entries, it can be made to work. The ID entries in , [iMAGE], and [COMPONENT] sections aren't special; they aren't magic names or anything, they just allow things to be linked together. So for instance, the start button [iMAGE] has ID=StartButton, and the three [COMPONENT] entries for it all have Image=StartButton in them which links them to the [iMAGE] entry. If the image had ID=BugsBunny and the three [COMPONENT] sections all had Image=BugsBunny, it would still work. The same applies to colors. For instance, there is a entry with ID=Pink, and several [iMAGE] entries have ColorKey=Pink in them. "Pink" isn't a magic name, it merely links the [iMAGE] entries to the right entry. Using "TasmanianDevil" would work just as well. In this particular example, all the [iMAGE] sections all have Transparency=None or Transparency=Alpha in them, so the color-key setting doesn't actually do anything. If you had an image with pink representing the transparency color, you would need to set Transparency=ColorKey in the [iMAGE] entry to make it work. By contrast, the Component= entries in the [COMPONENT] section *are* magic values and tell SmoothText which component the section relates to. So for the start button, the three [COMPONENT] sections all have to say Component=StartButton. At this point, SmoothText doesn't (yet) support using alternate Explorer icons. I know how to do it as I've already done it for my test version of TClock3, I simply haven't gotten to it yet. The .INI file I included skins everything that SmoothText is currently able to skin. Does this help? Feel free to ask me any more questions, and thanks for trying it out

Colonel O'Neill, I've recompiled the SmoothText 0.9.1 DLL with all of Delphi's debugging options enabled. I don't know if it will help, but I'm hoping that it will yield a more complete stack trace when FastMM detects an error. Hopefully this will help me better track down the problem(s). Unfortunately I'm not seeing any errors at all, so I'm going to have to rely on you to help me. Would you mind giving it a try? http://www.savefile.com/files/2087811

Oops, I forgot to include that DLL. I fixed the ZIP and re-uploaded it. What happens if you try it now?

I made a lot of progress today, and as of now, SmoothText 0.9.1 is up (see the first post in the thread). The skinning engine is very incomplete, but those parts that are finished are working pretty well. I'm aware that much more needs to be done (toolbars are quickly becoming the bane of my existence, for instance), but I hope you all like it. Enjoy...

Wow, I'm amazed that Win7 likes it. Before I release version 0.9.1, I'll double-check translucency. I've switched to a different memory manager and that seems to helped things a lot. The preview is almost ready, I'm sorry about not releasing something tonight but it literally took me all day to hunt down a major bug that I would consider a showstopper. Now I have to fix some visual glitches, but I think it's nearly releasable (not at all complete, but at least I'm not embarrassed of it now). Maybe another day or two, depending on how quickly I can nail down some details.

I'm going to try to get a preview out this weekend, though skinning definitely isn't complete. There isn't any import capability yet, so you'll have to edit the .ini files by hand, but I'll include an example .ini file with it.

I'll see what I can figure out. I found that some of the "Could not send message" errors aren't really errors. The way Behavior's work is they first activate their message "group" and then set themselves as Active. This is on purpose, but it also results in a race condition where they can receive internal messages without actually being active yet. I stopped logging errors for that case since there's really nothing wrong with it. I've made some progress with skinning, by the way...

I honestly have no idea. I suppose you could try undoing it. Is it just a registry change, or does it involve patching the file? Either way, it doesn't sound like the sort of thing that should cause problems, but you never know.

I honestly don't know how to lock the taskbar. Actually, I hadn't even noticed that they couldn't lock until you mentioned it No, the top part isn't being drawn yet. I have to add a generic overlay window manager first. A lot of that code will come from TClock3, though I'm pretty sure that I can greatly simplify it by changing the design.

Changing the font will be really easy, I already do it in TClock3. It's just a matter of creating the font before I paint. Adding support for animated images will be the harder job, for instance. Even then, most of the code is in TClock3 already, albeit in a different form that requires some changes when I bring it over. I'm being very careful to not sacrifice any stability when I bring it over, so it takes time. SmoothText will be able to handle "orb" start buttons, too, I simply have to port the right code from TClock3. I already have the non-orb portion mostly working. There will be four shadow settings: - None - Simple - Soft - Glow The example above shows the simple and glow settings. Each image component can have its own text color, shadow color, and shadow setting, so you'll have complete flexibility. I'm not skinning window borders yet, but when I do, these settings will follow just as they do with everything else. I'm running plain-vanilla SP4. I once tried a clean install of SP5 on another box maybe a year ago, and it crashed repeatedly. I've tested this on multiple SP4 boxes with few/no problems, so you might want to try it on SP4 to see how it treats you. Here's where I am tonight:

Here's another update: (added shadowing/glow effects) At a minimum, I need to add Start button support and try to fix a glitch or two. It would be nice to also have the ability for the skin to set the font, but I'm willing to release what I have before then.

Hmm. Sounds painful. I guess I'll cross that bridge when I get to it. Here's another update: One little bit at a time...

I want to fix the problems with taskbar transparency and use that mechanism for general transparency. That would let me handle transparent window borders. I have no idea how to handle blur, though. I get some exceptions from time to time, too, it's just something I have to investigate. Here's a screenshot that shows how far I've gotten so far with the taskbar:

Thanks for the post. I'll have to devote some time to squashing the remaining exceptions at some point. At the moment, I'm working on skinning, which is turning out to be pretty easy since a lot of the code is coming from TClock3. So far I'm skinning: - buttons - checkboxes - radio buttons - taskbar background (except the gripper area) - taskbar buttons - quicklaunch buttons - extra toolbars on the taskbar - rebar controls I still have a lot more work to do on toolbars, but a little bit at a time it's getting there. There is no import or editing capability in as yet, I have to build the skin .ini file by hand; there isn't any point in doing an editor or importer until the engine is nearly complete. I also haven't done anything yet with custom fonts or text colors, they're still the Windows defaults, so for the moment I need to use a taskbar skin where black text shows up. Things are progressing smoothly, though, with no loss in stability.

It works like TClock3/WB in that for each edge you can specify how much isn't stretched. You can also specify whether each edge is stretched or tiled along the edge, and whether to stretch or tile the center portion in the H or V directions (or both). It's very flexible, in some ways much more than WB. For instance, you can completely specify how frames are arranged in each image file (horizontally, vertically, or both), whether they go top-to-bottom, bottom-to-top, left-to-right, or right-to-left (or a combination of them). You also aren't limited to any frame order when it comes to image states: you instead specify the frame location for each state individually, so this way you should be able to import just about any skin.

Excellent, glad to hear that your system is stable now. I thought I'd post this. This is the very beginning of skinning...

Well, at least your Explorer is back up and running again. The trick seems to have been removing code that uses Delphi's reference-counted long strings and using null-terminated ones instead. Apparently Delphi's way of managing them is incompatible with Explorer (at the point where they interface, at least). I might take it further and completely expunge reference-counted string code from it just to be sure, but that would be a huge job. I'd rather not do that if I don't have to. Anyway, I'll still have to figure out why translucency isn't working for you. Can anyone else chime in? Is it working or are other people having problems with it, too? The more information I have, the better equipped I should be to figure out what the issue is. I've posted version 0.9.0, which fixes a crash bug in Firefox 3. It happens in file open/save dialogs when you right-click and select New... as if you want to create a new folder, for instance. Apparently you have to be very careful in choosing where to send owner-draw messages to. I can't believe this is up to 0.9.0 already...it's sure come a long way.

-loadini=<inifile> I haven't worked on TClock3 in quite some time, as SmoothText will be replacing it. By the end of April, I'm hoping, SmoothText's skinning engine will be running (though likely incomplete).

Oops, sorry about that menu regression bug. I've posted version 0.8.9, which fixes it. Out of curiosity, what color depth are you running? Is it 32-bit or something lower? I haven't tested transparency in anything lower (like 24-bit) and I've been wondering what would happen.

I've posted version 0.8.8, which on my PC seems much more stable. I've made a lot of internal changes, and hopefully this will work a lot better. Please let me know what you think. It would be nice if SmoothText came with at least one skin, but I'm not ready for that yet. First I need to make it stable and then I'll start on a skinning engine.

The number in the filename is the process ID. If you look at the bracketed numbers in the log, the first number is the process ID and the second number is the thread ID. Breaking it up this way makes the logs a lot easier to follow to try to find root causes. I take it that the translucent taskbar is working for you now? The strange thing about the log you attached is that the completion status shouldn't be empty. I don't know why that is so. I've started laying out the classes for a skinning engine, but I want to write one from scratch, one that's hopefully very flexible. As far as using existing skins, I'm thinking that standalone import program(s) are the way to go.

Aha! I had accidentally broken the code that retrieved the tab text. I found that I was seeing the same exceptions you were whenever I had the control panel open. I managed to fix it, and the exceptions are gone. Version 0.8.7 is now up, and I think that will solve the exception/crashing problems.

The first tooltip one is really bizarre. It's throwing an exception on a WM_USER + 7, and the tooltip isn't even subclassed; I would expect Windows to just throw the message away. The log looks like the tab painting routine is wigging out. I'll work on that one tomorrow, but in the meantime I've posted version 0.8.6. It has a small change to the button-handling code that is the first step in preparing for a skinning engine (I separated the actual painting code from the code that sets it up). I also improved the logging so that the log will show a string indicating how far it got before the exception was thrown. It doesn't have too much granularity yet, so for instance in the tab painting errors all it would show is that it's handling tab messages. I put all this in before I saw your second log. More to come tomorrow, probably, but why don't you give this a try.

LOL, I thought that 255 would be enough That was easily fixed, and I've posted 0.8.5 which will first find out the caption length and get the whole string. I'm glad to hear that you're not seeing crashes, though I'd be interested to see your exception log. Ideally, there should be no exceptions so I would like to try to prevent them.