LiteStep.net Forums

Hi,

some themes will not load/install, instead there is an errormessage "could not locale module, check your configuration". Example: 'Haga'

I have added all the extra DLLs to c:\litestep (and later even to c:\windows\system32): MSVCP70.DLL MSVCP71.DLL msvcp80.dll msvcr70.dll msvcr71.dll MSVCP60.DLL mfc71.dll

Is there anything else I can do ?

THX jc

I get the same with a bunch of modules using the theme 'Simple Dark' loacted here http://customize.org/litestep/themes/51173
it cannot find
mzscript-1.0.1.dll
xlabel-4.0.dll
xtaskbar-2.0.3.dll
xpopup-2.0.dll
xtray-2.0.1.dll

all are located in C:/LiteStep/modules

jc999: what module could it not load?

When the error message shows up, give focus to it, and press CTRL+C which will copy its contents. Please paste the result here.

Hi Jugg,

thank you for your reply.

The theme is "Haga", downloaded a few days ago (http://www.themes.ls-universe.info/download.php?view.29)

Here the dir-lines from c:\litestep\modules (all dlls are there):
02.07.2007 11:57 39.424 xdesk-1.0.dll
04.07.2007 17:18 9.216 jkey-0.39.dll
04.07.2007 03:24 68.608 xtray-2.0.1.dll
04.07.2007 03:24 100.352 xtaskbar-2.0.2.dll
04.07.2007 03:24 186.880 xlabel-4.0.7.dll
02.07.2007 11:57 175.104 xpopup-2.0.3.dll
04.07.2007 17:18 4.100 args.lua.dll

Here the error-messages:
---------------------------
C:\LiteStep\modules\xdesk-1.0.dll
---------------------------
Error: Could not locate module.
Please check your configuration.
---------------------------
OK
---------------------------

---------------------------
C:\LiteStep\modules\jkey-0.39\jkey-0.39.dll
---------------------------
Error: Could not locate module.
Please check your configuration.
---------------------------
OK
---------------------------

---------------------------
C:\LiteStep\modules\xtray-2.0.1.dll
---------------------------
Error: Could not locate module.
Please check your configuration.
---------------------------
OK
---------------------------

---------------------------
C:\LiteStep\modules\xtaskbar-2.0.2.dll
---------------------------
Error: Could not locate module.
Please check your configuration.
---------------------------
OK
---------------------------

---------------------------
C:\LiteStep\modules\xlabel-4.0.7.dll
---------------------------
Error: Could not locate module.
Please check your configuration.
---------------------------
OK
---------------------------

---------------------------
C:\LiteStep\modules\xpopup-2.0.3.dll
---------------------------
Error: Could not locate module.
Please check your configuration.
---------------------------
OK
---------------------------

---------------------------
C:\LiteStep\modules\lslua-0.5\args.lua.dll
---------------------------
Error: Could not locate module.
Please check your configuration.
---------------------------
OK
---------------------------

@EasyMeat

I get the same with a bunch of modules using the theme 'Simple Dark'

same here :-(

At least for the "xModules" you need xPaintClass-1.0.dll!
It's all mentioned in the module docs, but in this case the themer has made a mistake (he forgot to load xPaintClass-1.0 in the theme.rc).
You can either load xpaintclass-1.0 with NetLoadModule BEFORE every other module or you can download and extract it manually to your Litestep folder (next to lsapi.dll), in this case you don't have to check themes in the future.
You can download xPaintClass-1.0 at http://www.ls-universe.info/download.php

ls-universe: That would cause the "Cannot find xPaintClass-1.0" error.

All I can suggest is to update your builds at http://www.lsdev.org

@ls-universe: thank you, now simpledark loads without error and Haga has "only" one error left, no-locate-problem with C:\LiteStep\modules\lslua-0.5\args.lua.dll

@all
I must say that this kind of thing makes LS an experts-only tool. I am certainly no beginner, neither at computers and windows in general nor at programming. And I spent hours (really!) chasing along completely the wrong path because the error-messages pointed in a very wrong direction.

If LS is meant for widespread use then this kind of issue should IMHO not happen. I also know many people with years of professional computing experience, like network-admins, GIS-experts and the like who will be quite capable of using LS but will not (can not) spend time going after this kind of error.

I also know many many "normal" users who would be happy to have something like LS for lots of reasons, but are not capable of identifying solutions of this kind.

These are the kinds of small errors that

a) are very easy to solve once and for all at the base (meaning the distro)

and

b) have a devastating effect, locking out 90% (in mean it) of potential users simply by frustrating them in the first few hours. Those 90% will just give up.

No one will read the module-doc under these conditions. The problem occurs at least in 2 Themes, see above, and there is no reason at all (unless you already know) to search in the right direction. To someone outside LS it looks very much like a bug in LS itself.

The xPaintClass-Problem could AFAIKS be solved simply by including xPaintClass in the LS-distro AND by redesigning the error-messages.

There are at least 3 different errors all apparently causing the same message:

1) the module itself is missing
2) MSVCP70.DLL or the like is missing
3) another module like xPaintClass is missing

That is enough to shoot down anyone who is not willing to spend hours or does not have hours of spare time or who is not savvy enough.

IMO LiteStep only makes sense if it is a tool for many people, not just for relatively few LS-experts.

I do unterstand that an enormous effort has been put into LS and many people worked really hard to make it what it is. And it is a really great tool that deserves to be used by many people.

So what I ask is: please check and clear up the few remaining "bugs" that hit every LS-newbie. It will be only few, they will be small, but they are REALLY annoying and cost lots of wasted time and energy to lots of people who would love to actually use LS.

THX, jc

sticky

That reminds me, how's LOSI coming along? We'll be celebrating its 2 year anniversary soon!

@DeViLbOi

That's exactly what I meant. That was a reply to one third of my post, graciously ignoring the important 2 thirds.

In my post there are three groups of people:
1) People with a lot of time
2) Computer-Professionals who don't have time
3) People who are afraid to open a textfile

":: Forums :- General :- what is litestep?" says that group 3) should not use LS. Fine, then so be it.

That still leaves 1) and 2). Is it really necessary to frustrate 90% of those, cost them hours of time, and just because a few trivia in the distro are not thought out?
Don't be irritated because you actually know LS-users. Those are the remaining 10% of the above. You will never even hear about the others.

For who was Litestep made?

Wasn't irritated or upset by your comments, was just pointing something out is all. And I have always stated that LS needs to work on #3, which should help groups 1 and 2.

And to answer your question, LiteStep was made for the tweakers that are never satisfied by anything.

jc999: The Litestep core can not really distinguish the reason why a module fails to load. Either it fails or it doesn't. Of course extra error detection could be added by someone who has time and is interested in solving the problem.

What it really boils down to is a distribution to be maintained that would be updated with new dependancies as new modules are released. We had a distro like that at one point, but the author disapeared and never released the source code.

ps. http://www.dependencywalker.com/ will help you with any future .dll loading problems.

@DeViLbOi: My apologies. Spontaneous overreaction :-)

@jugg: I used the "omar"-installer. And I must say IMHO the guy did a good job. It works out of the box. Is that the author who disappeared?

If that is so then I would like to make a simple suggestion: Have someone (might even be me ;) put a zip with dependencies on the litestep.net download-page and add a bold line to the section "LiteStep Installer (omar)" saying that this ZIP really needs to be added to the installation.

The idea being that no one can download the omar-installer without seeing that remark. This simple measure would have saved me lots of time and nerve. And I am sure that I am not the only one.

The combination omar-installer + dependency-zip or -installer would result in a very usable distro that would immediately work with many current themes. And you can start tweaking a little later.

jc

It wasn't that no themes would work...it was just the themes you picked didn't because they depended on a module. Originally xpaintclass could not be downloaded with NLM but that was recently fixed. Now we just need the themes to catch up. The Readme for the theme should have given you all the downloads like that that you needed to snag. So it falls on the themer and not the core.

Yes, of course. You are right, it is not the fault of the core.

To clear up what I wanted to say: LiteStep is a really great piece of software and all the people that worked on it have done a really great job.

I believe that LS could and should be used by many more people and would promote not only LS itself but also free/GPL-software in general.

That's because it illustrates one very important point that most windows users (including computing experts) seem to have missed so far: the shell and the OS-core are two separate things (as every linuxer already knowns). That is something MS does NOT want you to know, because that would partially corrupt one of the most important illusions that surround Microsoft: there is no other god.

I started using LS very recently, so I know exactly what the problems are when you start at zero. And I know that part better that anyone who has already solved and consequently forgotten the startup problems.

I found that some problems can be solved by doing a bit of doc-reading. I spent some time modifying the austerity theme, and I was successful at reaching my goals (functions of taskbar, desktop, hotkeys, vwm, switching a few modules to "x-Module"). So, I know how doc-reading works.

But another problem could be solved only after lots of checking in a large number of obvious but very wrong places: half the themes did not work. I mean: half. Not one, not two, but many.

It works like this (as LS-beginner, not later): you install LS, find it to work out of the box (yippie, happy!).

Then try your first new theme. Fails for some reason. No problem, try another. Fails again. Try a third one, works (relief!). Try a fourth one, fails again (real frustration!). You get the idea.

That is the kind of situation you will not obviously blame on the themes. You just don't expect half the themers to post non-working software. Instead you wrongly assume a problem with the core.

And find out only much later and after hours of checking and posting and discussing and reading that you only missed one single module (xPaintClass-1.0.dll) and maybe a few MS-DLLs (MSVCPxx etc).

So obviously and as you say it is not the fault of the core. What I am suggesting is that it can easily be solved at the level of the core, even if that is not where the fault lies.

One simple bold text-line in the omar-installer-section of the download page can save many LS-beginners lots of frustration. The line would be:

If you use this installer you MUST also install the following dependencies: MSVCPxx and xPaintClass-1.0.dll. Do that immediately! Disclaimer: this is not the fault of the core, but the core solves the problem.

This line must be right beside the download-link for the installer. Not in the docs, not elsewhere on the page, not in the forums.

Is that too much to ask? Seriously?

I get what you are saying, but it really is a theme related issue.
xPaintClass is not the first thing to catch themers out, nor will it be the last.

Themers just need to be vigilant when they release themes.
Also admin verification can be a bonus also (eg; NBI-Studio only archived working themes, but that site is going very slowly)

But the core does need better error messages. I was sure xPC related issues casued an "xPC not found" error... :/

jc999: I understand where you are coming from. I really do. But you have to understand that xPC was a module released recently where omar's installer is what...3 years old now. We have over 1300 themes uploaded and 3/4 of them were released before xPC came out so they don't have that dependency. For a good while xPC had to be in your LS directory so it would work. When themers uploaded their themes they should have specified in their description "Hey I used xPC, make sure you have it." It is not the fault of the installer or core build, but the themer.

I've been thinking about creating an "update" installer to Omars base distro for a while, but simply haven't made it a priority. Basically taking Omar's installer, wrapping it and various upgrades inside of another installer. Hackish, but it'd help bridge the gap until LOSI gets flushed out.

But then, I'd rather contribute that time/effort to LOSI itself if I were to take the time to mess with an installer.

jc999: I understand what you are saying, and pretty much agree. Out of the box experience should be a lot nicer, but what we're dealing with is new mixed with old. Any chance you have the motivation to take the idea of creating an updated wrapper install around Omar's distro?

Sounds like a good idea to me.

I would rather make an "updater" instead of a wrapper, reason see below. The important part would be a bold line of text next to the omar-download-link saying that the updater has to be used after installing the omar-distro and before applying any new themes.

As I tried to point out: The problem is not to update LS, that is pretty easy. The problem is for the newbie to quickly find out what has to be updated.

For the moment I assume that
- the MS-DLLs can be legally included in such an updater
- the only necessary update would be adding the extra DLLs
- Putting in too many DLLs is no problem. Any unused DLLs will simply be ignored by the core.
- really inexperienced users can use the omar-distro without adding themes
- the necessary DLLs would be:
MSVCP60.DLL
MSVCP70.DLL
MSVCP71.DLL
msvcp80.dll
msvcr70.dll
msvcr71.dll
xPaintClass-1.0.dll
plus probably a number of other DLLs that would have to be named be anyone who has had trouble with missing them before

While we are at it we could include the current distro in the updater (I mean the contents of LiteStep0.24.7_31-114.zip). That only contains a few files to be put in the LiteStep-Dir and could be handled the same way as any extra DLLs.

One major problem I see with a wrapper or a fully automatic updater is how to determine the LiteStep-Dir under all existing windows-flavors. I have no idea how to do that and I fear that any attempt on my side to do so would result in an updater that works for some people and does not for others. Meaning we would have the old problem with a new software. Some progress :-)

An updater would therefore either copy all necessary DLLs to the litestep-dir or contain one single and final readme.txt instructing the user to manually copy all files to that dir.

Since LS is only for more experienced users it should be sufficient to have a ZIP with DLLs + readme. Provided that no one can download the omar installer without being loudly warned about updating, of course.

I only have XP, so I cannot test 2k or 9x, but I would at most only create a batch-file anyway. That should then be portable to 2k/9x if it is simple enough. But again: how does the batch-file find the LS-Dir?

And one more IMHO serious issue with a wrapper around the omar-installer: The wrapper would have to first call the omar-installer and then update the files. But, if I remember correctly, the omar-installer asks you to reboot immediately after install.

If the user then follows that expressed recommendation the PC will reboot and the update-process will never happen. The user might even think that everything is all right since he used the new and improved installer.

That could be dealt with by making some really messy changes to the RUN-section in the registry or the autostart-folder. That would probably fail if the user does not have admin-rights and the procedure may even be different for every windows-flavor. And I wouldn't even want to start thinking about vista.

I think a really simple but well documented and non-ignorable file-collection is the right solution.

Nice to see a fresh face (umm name) who wants to get involved right off the bat. Thanks, jc.

All of those DLLs you named off and I think we only have need for 2 of them? Then you go down the list and you are fine up until the last one which is not a DLL, it is a LiteStep module. Again, to "fix" the problem you had with the theme all you needed to do was include and NLM line for xPC to be loaded first and all your headaches would have gone away.

jc999: Omar's installer creates a registry entry with the location it was installed to.

key: "HKEY_CURRENT_USER\Software\LiteStep\Installer"
string value: "LiteStepDir"

The items that need to be updated/added are:
* LiteStep Core Build 0.24.7 Final
* NetloadModule 2.5.0

As Dev points out, it really is the theme's responsibility to include xPaintClass. Although it wouldn't be wrong to include it in an installer/update either. As for the msvc*** system dlls. There are several modules that depend on the 60 and 71 versions. I'm not aware of any that need the 80 versions. Look at ls-universe.info for a "System Dll's" pack linked off the front page.

@jugg: OK, got it.

I created an updater, a ZIP-archive with a readme, an update-script and with every relevant updatable file.

The update-script (batch) was tested on XP and may work on 2K. It will not work on 9x. It checks for the LS-Dir, checks if LS has been stopped, and if both are OK it updates the files.

The archive can also be used for manual update simply by stopping LS and then copying everything to the LS-Dir.

The "System Dll's"-Pack contains MSxx80.dll. So I included it too. No damage done if it is not used.

And I included LiteStep Core Build 0.24.7 Final, NetloadModule 2.5.0 (in subdir NLM).

I also included xPaintClass-1.0 , which is of course not part of the LS-core, but which is and will be for some time one of the main causes of big trouble for any newbie. Helps often and no damage done by including it.

The archive has about 1MB. If you are still interested let me know what you want me to do with it.

PS: I tested it on a new LS-install and I updated the LS that I actually use. Since I am able to write this post my LS seems to be alive and well :-)

I totally agree with including the MS dlls, although all it took to bridge that hurdle was a quick google, which you'd imagine almost any litestepper would have no problem with.

xPaintclass is now netloadmodule'd, and like dev said it's just the out of date themes that will pose a problem, although I suppose it wouldn't hurt to dump it into the ls folder for good measure. Could be a little confusing if that version of xpc become obsolete, so you wind up with 2 different versions.

But hopefully LOSI will finally turn up and some things will change.

yea...I don't know what would happen with them both being around. Since the old xPC that belonged in the LS folder wasn't included, it was just called, who knows what would happen. Someone should test this out...unfortunatly I don't have LS loaded right now to do it.

xPaintClass readme says:

Put xPaintClass-1.0.dll in your Litestep Folder!

Simply overwrite an eventually existing older version!

If you have another version in your Module Folder, overwrite it with this one too!

Latest version loads via NLM though which would put it in the modules folder.

I checked and deleted both xPC.dll in c:\litestep and c:\litestep\modules. There was some strange error after restarting LS, but after the next logon austerity worked (obviously). The I inserted

*NetLoadModule xpaintclass-1.0

in theme.rc of the haga theme. Then xPC.dll was automatically loaded in the modules-folder. So I'd say that is where it belongs by default.

But: if I did not also put it in C:\LiteStep I got some "xpaintclass not found"-errors even after reboot. These disappeared after putting xPC.dll in C:\LiteStep. So for some reason xPC.dll seems to be important in both directories. *WEIRD*

Important detail for any one (beginner) who wants to experiment with manually inserting deleting modules: it is safe to reboot afterwards, otherwise errors may happen that vanish forever after the next reboot.

Reboot is it. It is not sufficient to Logoff+on or to kill and restart LS.

See...but that is the problem. The older versions of xPC had to be in the c:\LiteStep folder, if they were in modules they still couldn't be found. So what happens if you have an old one in c:\LiteStep and a new one in c:\LiteStep\modules?

@DeViLbOi: no, I checked that right after you first mentioned the versions. I only have one. Same filename, same filesize, same MD5, independent of whether NLM downloaded it or if I d/l it manually. No version-problem here.

It still seems to be necessary in both directories. Don't ask me to explain, that's experiment only.

It is only necessary in both directories if themes didn't load them via NLM.

Maybe. Why is that so? AFAIK NLM only puts the file in its directory. Or does it do any other changes to the LiteStep-config or the system?

If yes: what else does it do?

NLM puts the module and docs into the modules folder... It checks this folder to see if the module is already present (in the modules folder) first of course. Once it's there, it's not redownloaded, and it is used....

Earlier versions of xpc needed to be in the root, and could not be NLM'd. Once this became possible, only themes which didn't NLM xpc need it in the root litestep folder, as if it does NLM xpc then it uses the modules folder one....

There shouldn't be too many themes which don't NLM it... I suppose it might not matter to keep an xpc in the litestep root, simply to save those themes which haven't NML'd it, but it's not that big a deal IMO.

After I started using LS (recently) I downloaded quite few themes and I ONLY took recent ones (those that came first in the lists sorted by date). That is something very sensible for a LS-newbie to do.

Now I can without further research name 4 themes using xPC, and only one of those NLMs it. (so 75% non-NLM)

This is of course only a problem for LS-newbies. Unfortunately even if you load a theme that NLMs xPC, you are still not out of the woods, because, as xanmolbjerg explained, many themes, even recent ones (see above) expect xPC in the LS-rootdir.

At that point even the doc-reading newbie has had it. He knows he already has xPC, and he would also explicitely have to know that NLM-ing xPC is NOT enough, but xPC ALSO has to put in the rootdir.

I really know what I am doing and I had real longtime trouble getting that clear.

So, yes: xPC must for the time-being be in the LS-rootdir because otherwise any newbie will be maneuvered into a really absurd situation, even if he reads every doc on the market (Nobody does that of course. Normally you try a few themes, find a large part non-working, and do the one reasonable thing: put LS back where you found it and forget really fast.)

Agree'd...my concern however was if lets say for example xPC 2.5 was in the modules folder and xPC 1.0 was in the LS folder...which one is actually being used by LS when the call is made? If some new feature is added into 2.5 but LS is auto-including it out of the root folder what happens?

I'll explain the problematic points (and history) of xPaintClass:

1. xPaintClass was planned as "Core dll"
-> Placed in root LS folder like lsapi.dll
It was planed that it is included IN THE ROOT FOLDER by LOSI the new installer and therefore standard in recent LS Installations.
Because it should be updated with/by the installer/builds there would be no problem (same name) with versions.

2. LOSI couldn't get finished in reasonable time (and still isn't)
-> xPC Release (last year) WITHOUT an automatic installation
-> People complained that it requires a manual installation, which doesn't allow theme releases.

3. The NetloadModule version was created to allow releasing of themes
-> The problem with different "Updates" started, because the name must remain the same (like lsapi.dll).

That is very problematic, but could easily be fixed with an working installer.

The upcoming version of xPC Update 4 is probably really the last for some time!
Except the case that bugs are found (as happened in the previous versions).

Usage:
xPaintClass-1.0.dll should be in the LS root folder (and only there).
You don't need it in the Module folder, in fact it won't work at all if you use "NetLoadModuleAlwaysUseFolders"!

-> Atm a user should keep his version up-to-date by visiting LS-Universe.info once a while and put the latest version in his LS Root Folder.
NetloadModule lines can be removed, EXCEPT someone wants to release a theme!

Andymon

If the module was intended to be released as core why was the source not turned over to the dev team for inclusion with all builds?

Dev: Andymon and I have been talking about it recently actually.

Andymon: What does the "netloadmodule version" do to function correctly? Set the lookup path for LoadLibrary to include the modules folder?

First of all: I don't know much about dll's loading routines!
xPaintClass is linked in the modules with its lib, like lsapi.lib!
And if the dll isn't in the Litestep Folder it isn't found -> the module won't load!
If its loaded as module (with dummy initmoduleEx and quitModule), then it works in the module folder as long as "NetLoadModuleAlwaysUseFolders" isn't set. That's all.

Probably there is a way to make this much better, but i don't know it. :|

Little experiment:

I deleted xPC.dll from /modules and put it only in the LS-rootdir. Then I rebooted, just to be sure that nothing is left loaded in memory.

Then I use 3 themes that depend on xPC: necessidades3.0, Haga and Sysy-1.0.

Sysy-1.0 NLMs xPC, the other two don't. So I also changed theme.rc of Sysy-1.0 and commented out the line that NLMs xPC. That way xPC was not auto-loaded into /modules.

Then all three themes work, so apparently it is really sufficient to put xPC into the LS-rootdir.

There is another problem though:

If I start randomly switching between the 3 themes named above plus the austerity-theme I find that certain combinations cause errors. It seems that switching from necessidades3.0 to Haga always does this, other combinations sometimes cause the error.

Sometimes the LS-core crashes, at other times it just leads to an incomplete theme. The error is "stable" in the sense that I have seen this several times in the past days during diffent windows-sessions. It is not "stable" in the sense that it is easy to reproduce, except AFAIKT with the theme-combination I named above.

There are usually two errors-boxes "Error during module-initialization", from xtray-2.0.1.dll and NLM\NetLoadMdoule2.dll.

The point here is this:
All 4 themes work without error if activated a second time, even it LS did not crash. So all the themes are OK and it is not an obvious error made by the themer.

It would seem to me that loading and unloading modules during theme-change can destabilize the core, and I would like to suggest testing the core against this kind of situation.

And there is one more really annoying and unreproducable issue.

I use the windows-quicklaunch in all themes and usually deactivate the quicklaunch-bar that comes with the theme.

Sometimes it happens that the icons/menu-items in the quicklaunch-menu disappear. The menu itself is still there, just the contents are gone. No theme-switching will help, nor does killing and restarting the core.

The quicklaunch is just empty and stays empty until the next reboot or logoff/logon.

This happens randomly and without any reason that I can identify, but it happens quite often, sometimes even in sessions where I don't switch themes or modify anything else in LS.

jc999: Let us know when you have that upgrade archive ready. I'm sure other people would like to test it.

It would seem to me that loading and unloading modules during theme-change can destabilize the core, and I would like to suggest testing the core against this kind of situation.

Buggy modules that do not correctly release their resources will cause this to happen. There isn't much the core can do about that. If you can isolate what modules are causing the problems, I'm sure those module authors would be happy to hear about it and fix it.

I use the windows-quicklaunch in all themes and usually deactivate the quicklaunch-bar that comes with the theme.

I'm not sure what that means.

jc999: Let us know when you have that upgrade archive ready. I'm sure other people would like to test it.

Oops, sorry, that must have been not big enough. On 07.07.06 @ 18:00 I wrote that it is ready and asked what to do with it now.

After that I made some changes due to the discussion on where to put xPC, but otherwise it is OK.

Buggy modules that do not correctly release their resources will cause this to happen. There isn't much the core can do about that. If you can isolate what modules are causing the problems, I'm sure those module authors would be happy to hear about it and fix it.

Here comes: Theme-switching can cause the following modules to crash LS: There are two errors-boxes "Error during module-initialization", from xtray-2.0.1.dll and NLM\NetLoadMdoule2.dll.

Closer description see above.

I'm not sure what that means. (quicklaunch)

Most themes have quicklaunch-icons in the taskbar. That's usually Browser/IM, Email, Filemanager etc. In the austerity-theme you can for example activate/deactivate these via the theme-menu in the bar-options.

There is also the quicklaunch-folder of windows. That would usually be "C:\Documents and settings\{USERNAME}\Application Data\Microsoft\Internet Explorer\Quick Launch.

This folder is responsible for the quicklaunch-bar in the "normal" windows-shell. This quicklaunch is included by default in the themes, somewhere in the standard popup-menu.

(In the austerity-theme it can be activated/deactivated with the variable UseRealQuickLaunchItems in themevars.rc.)

The menu-item is in the default personal/popup.rc:
*Popup "quicklaunch" "!DynamicFolder:$QuickLaunch$*.lnk"

That's the menu of which the contents sometimes disappear in every theme.

Upload it to the Downloads section here on litestep.net.

Posting here in an obscure thread about the particular modules having problems won't help. As I said before, contact the module authors (or the theme author).

What popup module are you using?

What popup module are you using?

The themes I use include popup2-2.1.4, xPopup-2.0 and xpopup-2.0.3. Can't say if any one of those is specifically the cause.

Upload it to the Downloads section here on litestep.net.

Sure, will do.

I did remember to mention that the point of the exercise is not promoting some new piece of software made by ME?

The point is that any (new) user
- must be told
- right at the start
- immediately visible
- and without any further doc-reading
- that an Update (not necessarily an updateR)
- is absolutely mandatory and is not a question of "option" or "later"

Obviously that I cannot do because all I can do I post some textlines somewhere in the Downloads section.

But even on that page that will be nowhere near any point where the new user will immediately see that he absolutely must update.

This is not a software-issue. The software is fine, even counting a few small and unimportant quirks. It is the issue of getting people to know some very few but important infos.

jc999: Thanks for uploading that.

I noticed that the update.bat file copies xpaintclass to the modules folder. I thought it was determined that should not happen? Along with that, perhaps a message should be stated there that any lines of netloadmodule xpaintclass should be removed?

Also prior to copying NLM, you echo a statment saying to reboot. Shouldn't that only be stated at the end of the script?

Also, if NLM doesn't exist, no message statement to reboot is displayed. However the core files were updated, so the message should be displayed anyway.

Finally, if one were to manually copy the contents of the archive, the readme.txt does not state that xpaintclass needs to be placed in the root folder. Because of that, xpaintclass is only going to be copied into the module folder when done manually. My suggestion is to move xpaintclass out of the module folder into the root folder of the archive.

Really cool job with this though. Thanks for working with us on it, and taking the effort to make LiteStep better.

Any suggestions on how to communicate the items you mentioned in your last post? Your update package is the first item listed in the LiteStep downloads section now, so that should help. Also I updated the description text in Omar's download as well (a couple of days ago, so it doesn't mention this updater yet).

noticed that the update.bat file copies xpaintclass to the modules folder. I thought it was determined that should not happen?

My mistake, did a little too much changing back&forth during the xPC-discussion. :-) Actually modules/xPC.dll is deleted first and then copied again. No sense there.

Now modules/xPC.dll is deleted during update.

... several comments ...

Right, am working on them now.

Added to batchfile:
Hint: When installing a new theme it is advisable NOT to auto-download "xPaintClass-0.1". Check the _readme on how to do that.

Added to _readme.txt:
Hint:
When installing a new theme it is advisable NOT to auto-download "xPaintClass-0.1".

Some themes try to download "xPaintClass-0.1" automatically. When "Netloadmodule: Required Modules" appears you should right-click "xPaintClass-0.1" and check "Do not download".

... plus short explanation on how to change theme.rc ...

Accidental auto-download of "xPaintClass-0.1" will probably not disturb your current LS-installation but it may cause inconsistencies in future updates.

changed batchfile:
- checked positions of the "please reboot now"-messages
- moved xPC to root-folder

OK, uploaded the new version.

Any suggestions on how to communicate the items you mentioned in your last post?

Actually I would say we already are on the right track.

I'll add an appropriate line to the description of the updater. That would then be the first bold line that the newbie sees.

I would say that and the reference in the installer-section will be good enough.

Hmmm, I don't think you should attribute/associate http://www.litestep.net/ in the readme for this updater as if the webmaster here is the one that created it. I would suggest that you put your own name in the readme. Only makes sense.

Also, xPaintClass-1.0 not xPaintClass-0.1

The update.bat file does not correctly install NLM.

It needs to move the .\LiteStep\NLM\msvcr71.dll to .\LiteStep\msvcr71.dll according to the NLM\install.txt

The batch file is confirmed not to work on Windows 2000. (Win2k does not have reg.exe)

However reg.exe comes in the Windows 2000 Resource Kit from Microsoft. Also an old version can be downloaded from:

http://www.petri.co.il/download_free_reskit_tools.htm

Thanks for the feedback.
All items fixed plus a few changes to the batchfile.

Now Reg.exe version 1.1 is included in the updater so it should work on 2k too.
Someone please test on 2k and let me know, thanks.

When you upload these you need to make sure you increment your version number, r1...r2...r3...etc. jugg can you go and do that voodoo that you do and move the one without a version to r3?

Somehow we got mixed up with the versions anyway. Today's version slipped into "old version without version-number" and the "current version" on the d/l-page seems to be from yesterday.

I would prefer to upload the definitive "r3" once more, that should clear everything up. Jugg, please confirm that I can upload once more, I don't want to add another stray version.

It was determined to be an "old version" because 0.24.7 comes before 0.24.7 r1. If jugg can get it to change to r3 it should be fixed, we were having some problems yesterday with it just disappearing when we changed the version.

OK, uploaded "r3" now. Should come in at the same time as this comment. I also renamed the archive "...-r3". Hope I got it right this time.

If possible please delete the other uploads from today.

Since the download is out there already I am just going to let jugg fix it. It will just be easier I think. You uploaded with -r3 instead of r3 and I think it will put it before the others anyway because I think space comes after -.

Sorry about the mess. I thought since all uploads need to be approved (says the site) that there would not be automatic processing that could be mixed up by my entries. Now I know better.

Jugg: Please delete all previous uploads from today except the last one (with the "-r3").

There are no pending uploads at this point.

So I try again...
As of now (07.07.10 @ 12:30) there should be one upload pending. At least I got the "Thank you for your submission ...".

I'll clean it up... ;)

Done. Should be good to go. This version works fine on Win2000.

Now that you have your feet wet with Litestep, what's next? :)

There is always http://tlundberg.com/LOSI/ if you want to help get the next full installer flushed out. :P

OK, I checked the update-version in the downloads, just to make sure. Checks out, same as my original.

LOSI: I just disabled the omar-installation and installed LOSI. Works. So far I did not find a single bug :-D

But frankly it is really boring. The default-theme is horrible (hope I didn't offend anyone too seriously) :-)

I think that some other theme, or better even two or three, should be installed by default. Personally I found the austerity-theme a good choice for a startup-theme.

Sure, you can always install a theme, but it is much more impressive if you immediately get something colorful that demonstrates "by doing" what LS is about. With Desktops, theme-menu, hotkeys etc.

Look at it with the eyes of a newbie: you install this software that you heard so much about and what do you get? A single-colored desktop and by default almost no controls. Only the standard-menu, not even a theme-menu (or did I miss that?), and no menu button (I do miss that). And only ONE desktop??? What do I need LS for? YAWN!

The default-installation should by itself be the argument to use LS in the future.

That is the kind of thing I could imagine having a look at. No promises! But if someone could quickstart me on how to use the LOSI-source, I'd like to do some experimenting, just to get a feel for it.

Join on IRC irc.freenode.net #lsdev and #litestep Tobbe is usually on those chanels, and since he's the one developing LOSI, he'll be able to point you in the right direction, and be glad to have your input I imagine.

The LOSI website should be able to get you the necessary downloads, and contact info etc.

*waves magic hand*
Ignore the theme. It's only there for beta testing the installer. Tobbe made it himself, and he is *not* a themer. Do not fault Tobbe. It should have been made clear that by the sheer utter boringness of it, that it wasn't made for casual consumption.

If you hop on over to ls-themes, you can see we had a LOSI Default themes contest. So, yeah ....

Pop on over to the IRC channel. Tobbe and I would love to get our grubby little hands on you.

heh, THC4k just removed the contest stuffs :|

*kicks self in head*
ugh .. *grumblse* silly thc