Wraith

Whoa, something weird going on there... The execute tags should have the fully parsed versions, so the #SOURCEDRIVE#\install\$$.exe -y -o"C:\WINXP in the logfile should should turn up as D:\install\$$.exe -y -o"C:\WINXP Very weird. I'll look into it when I have some time. Extremely busy right now, moving house soon.

Have you tried using XPlode to install it after first reboot? XPlode doesn't report any error with running the installer, so it can find the path correctly, and it passes the argumetns correctly, so it seems like it's a problem with the office installer. Try XPlode after first reboot and see if it's still screwy.

From what I can tell, this isn't an XPlode issue - try the application install forum?

.....have you checked the logfile? What paths does it say it's trying to run?

What does the XPlode logfile say?

Change all your &'s to & This is an XML issue, not XPlode.

Bad practice, pasting all that there. Attach it instead.

Ummmm.... use the one that comes with XPlode?

Puzzling. Because when I use the ico that you sent me, (Users2.ico), I get a broken image, as if it can't be found. My suggestion is to convert them to PNG-24 wtih alpha, then use the following in the style="..."; background-image: url(images/1px.gif); filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled='true', src='thenewpngimage.png', sizingMethod='scale'); You'll need a transparent image for (images/1px.gif) - I've attached one I've used in the past on other projects. EDIT: Okay, so attaching that image didn't work too well... 1px.zip

You're using *.ico's in the image attribute of the item tags? Or did you convert them to gif/png or anything?

Yeah, I still want the single images. There's ALWAYS a way to fix it

I mean the actual images you're using, not just the screenshot.

I took a screenshot then pasted it in photoshop, and made white transparent If people really need it, I can probably make an ico -> png converter, so it'll support 32-bit transparency etc. However, you'll need to fiddle with IE to get it to display them properly... You can try background-color: #FFFFFF; in the stylesheet - most of the time if they're transprent, they go to the background colour of the enclosing element, which is why I have no idea why it isn't white. Can you attach an image or two for me to have a look at?

Updated.

Okay, not THAT much of a pain. Fixed. Updated file is attached. XPlodeGFXInstall.zip

Yikes. There's something fundamentally wrong. LIke, REALLY wrong. Massive allocations whenever a plugin is run... gonna be a pain figuring out where. I'll look into it ASAP.

Ahh the problems with 2GB ram... you never see these things Can I get you to remove certain items within the XML, to try and narrow down which item is causing this?

Would you mind checking if XPlode is taking up all the RAM? Might've missed some memory allocations... Add "Memory Usage" and "Virtual Memory Size" to the columns in the task manager, if they're not there already...

I'll see what can be done... I have other priorities at the moment though No chance of that being changed - it was like that with XPlode 1.x, and people ALWAYS got things wrong. This way makes it harder to screw up.

Huh? You mean, a way to make always-selected, hidden item, which automatically gets installed regardless? If it's what you want, there's no real reason why it can't be implemented by someone else - the javascript.js handles that sort of thing. If nobody stands up to make the changes, I'll try and put it in the next release. Post a bug report and make it a suggestion.

Well, if you're happy with how it works....

Well it's just HTML, so theoretically you can go and set the <img> tag in the javascript to say width="16 height="16"

The selection plugin's XML has the WORKING syntax for the File Ops plugin. If in doubt, read the docs (Sorry, I forgot to update the XML's ) The beta version I'm working on has all the XML's updated. Mainly because I've re-added <include file="..." /> - I'll probably fix a few things the put out a maintenance release in a day or two.

You'll need to edit the javascript.js to do it. I'll leave that up to you ;-)

I have a feeling that it's something to do with encoding - as far as I know, the command prompt doesn't handle Unicode or multibyte characters all too well, and the accented "a" above does not exist in the normal ACSII character table. ---- I just did a test using XPlode, used this: <adduser display="Adding Mamá"> <username>Mamá</username> <password>test</password> </adduser> and it worked perfectly. So it's definitely an encoding issue. (XPlode uses Unicode for everything, including command lines for running programs.)