Litestep Tracker

vtray.dll

minor

always

2008-12-26 07:38

2009-01-16 16:19

den_po

none

feedback

none

open

Windows Update systray icon does not show

The Windows Update systray icon does not appear in the systray. Sometimes the icon "flashes" in the tray, ie. it shows for a split second and disappears again.

Windows Update client uses Shell_NotifyIcon with dwMessage unsupported by vtray (NIM_SETFOCUS and NIM_SETVERSION).

general

minor

always

2006-05-06 21:26

2006-05-24 00:12

lsdev

jugg

none

closed

none

fixed

The issue Status of "Assigned" does not make sense/ is redundant

The Status of "Assigned" can be set at any time, even when there is not developer in the "Assigned-To" field. Also other Status' may be assigned when there is a developer in the "Assigned-To" field.

It seems a more appropriate use of the "Assigned" status is to mean "In Progress" or "Active" or perhaps "Accepted". All of which kind of mean that the person the issue is "Assigned-To" is now working on the bug/issue.

Perhaps this would be a good usage of the various Status options:

New:
A newly submitted issue, no action has been taken.

Feedback:
Further information is needed before we can confirm or start working on the issue.

Acknowledged:
We have not confirmed the issue yet, however it looks valid and we'll look into it.

Confirmed:
The issue has been confirmed, and it appears to be valid. At this point no one is working on it.

Assigned (In Progress):
The issue is being worked on.

Resolved
The issue has been fixed and comitted to the source repository.

Closed
If the issue was fixed, then the issue has been included in a release.
If the issue was not fixed, then it was invalid and simply closed.

jugg

2006-05-24 00:10

Will change the text "Assigned" to "Accepted".

jugg

2006-05-24 00:12

Further work may still need to be done with this, but the confusing text is now at least changed.

documentation

text

N/A

2009-01-27 17:42

2009-03-07 06:28

jugg

none

confirmed

none

CVS-trunk

open

missing build_vc71.txt in CVS

The build_vc71.txt instructions are missing from the docs folder in CVS HEAD.

jugg

2009-01-27 17:44

I'm working on this... I need to test a fresh install of VC7.1, but it looks like the current code base compiles with the platform sdk that came with vc7.1. I might be wrong on that (perhaps I installed a platform sdk into my vc7.1 folder?)

In anycase, we need to decide whether to maintain instructions for linking against libpng/zlib, or just do away with that as the default is to use picopng now anyway.

ilmcuts

2009-03-07 06:28

Remove (or at least there's no need to update) the libpng instructions. Once picopng has 'survived' a release cycle we'll likely remove the libpng code anyway.

documentation

text

N/A

2007-10-09 17:30

2009-02-28 16:24

jugg

none

closed

none

fixed

Decision on LiteStep or Litestep naming convention

There have been several different naming conventions for Litestep over the years. We need to decide and standardize on one.

LiteSTEP
LiteStep
Litestep

The main question is whether the 'S' should be capitalized or not.

LiteSTEP - was the original form.

LiteStep - follows more closely the AfterStep convention. LiteStep was based on the idea of AfterStep, so this form makes sense.

Litestep - is cleaner as a single word, and has been generally used for the last few years.

We often abreviate Litestep as LS and LSDev. This would seem to suggest that the S should be capitalized. Our current LSDev logo uses LiteStep.

jugg

2008-04-22 02:12

I vote for "LiteStep"

Acidfire

2008-04-22 04:46

I also vote "LiteStep". It has more nostalgic value.

jugg

2008-04-28 15:15

So, officially we'll name/captitalize the LSDev Team's project as "LiteStep".

The capitalization "litestep" or "Litestep" in artistic representation is acceptable. However, websites, documentation, program output, and in everyday usage "LiteStep" should be used; particularly when refering to the product (ie. What release of LiteStep are you running? LiteStep 0.24.8).

The capitalization "LiteSTEP" is only acceptable when used in reference to the original 1.0 Betas released by Lonerunnr. It is not acceptable to use that capitalization in reference to the LSDev Team's project.

Finally, the capitalization of "Litestep Development Team" has traditionally always used a lower case "s". This remains a point of discussion. Perhaps renaming to simply "LSDev Team" would resolve this.

For a somewhat amusing look into the naming history of LiteStep, take a look at: http://irclogs.ls-themes.org/logs/freenode/lsdev/2008-04-23 [^]

tobbe

2008-05-14 16:05

If it's going to be LiteStep when talking about the shell I think it should be LiteStep Development Team, just to keep it consistent.

Acidfire

2008-05-14 16:09

I agree with Tobbe. LiteStep Development Team is consistent.

Acidfire

2008-05-14 18:11

Wiki updated to use only LiteStep and LiteStep Development Team.

documentation

text

N/A

2008-04-28 12:39

2009-02-28 16:23

jugg

none

closed

none

CVS-024x

fixed

LiteStep 0.24.8 documentation update

The documentation for LiteStep 0.24.8 needs to be updated to reflect the current state of functionality.

./docs/build_mingw.txt needs to be updated to reflect certain modifications necessary to the w32api headers before being able to compile.

./docs/changes.txt, math.txt, readme.txt and release_notes.txt all need to be updated. In the case of math.txt and release_notes.txt, these should be combined, and given a new name. Probably readme.txt should become release_notes.txt and the combined math.txt and release_notes.txt should become readme.txt.

We should also capture the contents of the current math.txt and release_notes.txt in a wiki page on lsdev.org.

jugg

2008-05-14 02:55

I'm currently working on this. So far I've cleaned up release_notes.txt.

TODO (release_notes.txt):
- merge math.txt.
- document CTRL+ALT+F1 recover menu.
- document image loading/icon extraction etc.
- document sample color values and "magic pink"
- ???

TODO (changes.txt):
- go through cvs commits and determine what has changed between 024.7 and 024.8

TODO (readme.txt):
- Update for Release Candidate 1

jugg

2008-05-29 03:19

I've updated the documentation... here is what is left that I'm aware of:

TODO (release_notes.txt):
- document CTRL+ALT+F1 recovery menu.
- document image loading/icon extraction etc.
- document sample color values and "magic pink"
- ???

jugg

2009-01-30 09:13

TODO:
- Update build_xxx.txt files
- Decide if we rename release_notes.txt to readme.txt and rename readme.txt to release_notes.txt for 0.24.8 Final release.

Acidfire

2009-01-30 14:34

I went through release_notes.txt as requested and don't have a lot of comments:

- Good job on the images/magic pink stuff.
- Why did you remove the litestep wiki from the links? Even though it's pretty much dead it's still a nice resource.
- The file should be a chm file and be named readme (and readme.txt should be release_notes.txt).

ilmcuts

2009-01-31 02:30

Minor nitpick: We also support "Windows XP Professional 64-Bit Edition" (that's the official name) as of 0.25.0.

The only other comment I have is that !SwitchUser works on Windows 2000. It locks the workstation. In fact, on XP and up, if fast user switching is disabled, it'll also lock the screen.

Only when FUS (Terminal Services) is enabled it'll switch to the "switch user" screen (also locking the workstation, effectively).

That said, maybe !SwitchUser should be renamed (but that's not relevant to this bug).

jugg

2009-01-31 19:49

Do you have some text to describe !SwitchUser correctly then? I'm not coming up with anything...

jugg

2009-01-31 23:31

Ok, I fixed those items.

jugg

2009-02-28 15:58

the build docs have been updated, and release_notes.txt renamed to manual.txt.

This issue is resolved.

documentation

text

always

2007-03-25 11:15

2008-04-22 13:08

phil

jugg

none

closed

none

fixed

CVS instructions not correct on lsdev.org

Using the instructions provided at the time of writing pulls out of date code from the CVS repository.

http://lsdev.org/e107_plugins/content/content.php?content.7 [^]

jugg

2007-05-05 14:26

Most of the articles on lsdev.org are out of date unfortunately. I am still working on the wiki which will replace the current website, and I'll be sure to have the article updated for the wiki.

ilmcuts

2007-10-09 13:57

It's now correctly documented here:
http://wiki.lsdev.org/doku.php?id=lsdev:cvs [^]

jugg

2008-04-22 13:08

This really isn't reported under the correct project. Do we need a Webpage project to track issues with the webpage? Maybe we should change the "mantisbt" project in to a "resources" or "tools" project, with categories for "mantisbt", "dokuwiki", "cvs" etc.

109

core

tweak

N/A

2010-09-03 15:00

2010-09-03 15:13

alurcard2

none

feedback

none

open

Provide API access to the Wow64FsRedirection functions

There are times when modules need to read from files or the registry, and when they do, they need to temporarily disable file system redirection, if they are on a 64bit os.

While module developers could easily copy the LSDisableWow64FsRedirection and LSRevertWow64FsRedirection code from the core, it might be a good idea to provide API functions for them so that they don't accidentally call Wow64DisableWow64FsRedirection directly (since it wont work on all systems).

It's very important that modules disable redirection before accessing the registry or file system, unless they know that they are accessing a part which will not be directed. Otherwise they may end up accessing the wrong file/key, or not finding the file/key at all.

The biggest problem right now is probably modules calling SHGetFileInfo, in order to get icons, without first disabling redirection.

alurcard2

2010-09-03 15:13

I forgot to mention it, but since Wow64DisableWow64FsRedirection will disable file system redirection for the entire thread (other modules and the core as well), it is extremely important that modules call Wow64DisableWow64FsRedirection as soon as they are done accessing the file system or registry.

110

core

minor

always

2010-09-03 15:04

alurcard2

none

feedback

none

CVS-trunk

open

Unable to open folders on some systems with the current version os LSExecute/Ex

For some reason, when file system redirection is disabled, which it currently will be on all x64 systems, calling ShellExecute/Ex with a directory path results in nothing happening.

core

minor

always

2008-12-28 03:23

2010-09-02 16:41

ilmcuts

none

confirmed

none

open

Changes to global environment variables have no effect

Changes to environment variables via sysdm.cpl don't propagate to LiteStep or its child processes.

For implementation hints (WM_SETTINGCHANGE) see http://support.microsoft.com/kb/104011 [^]

alurcard2

2010-09-02 16:41

You need to reboot your computer for them to update with Explorer as well.

core

minor

always

2008-01-12 08:44

2010-09-01 18:59

ilmcuts

none

confirmed

none

open

Shortcuts to 64-bit progams broken when running in WOW64

On 64-bit Windows there are both 32-bit and 64-bit binaries for some programs like IE, Media Player, or Calculator, in "Program Files (x86)" and "Program Files", respectively.
A 32-bit Litestep cannot currently invoke shortcuts to the 64-bit versions because ShellExecuteEx appears to read out FOLDERID_ProgramFiles from the .lnk, which resolves to "Program Files (x86)" for 32-bit processes. Thus the 32-bit versions are launched. Note that if only a 64-bit version exists it is launched all the same.

You could make a case that it's a bug in Windows setup as it should have set FOLDERID_ProgramFilesX64 in the .lnk files. However, FOLDERID_ProgramFiles may be correct for compatibility reasons. Anyhow, since we cannot change Windows setup and since the default Windows shell works correctly (it's a 64-bit process), we should try to find a workaround.

jugg

2008-04-30 16:50

qwilk of xoblite passed this along:

"0000039: Shortcuts to 64-bit progams broken when running in WOW64"
check this one out: http://msdn2.microsoft.com/en-us/library/aa365743.aspx [^]

"The following example uses Wow64DisableWow64FsRedirection to disable file system redirection so that a 32-bit application that is running under WOW64 can open the 64-bit version of Notepad.exe in %SystemRoot%\System32 instead of being redirected to the 32-bit version in %SystemRoot%\SysWOW64."

"To restore file system redirection, call the Wow64RevertWow64FsRedirection function."

you'd need to IsWow64Process first of course
http://msdn.microsoft.com/en-us/library/ms684139(VS.85).aspx [^]

// Check if running under 64-bit Windows... (for future use)
// ("IsWow64Process determines whether the specified process is running under WOW64.")
typedef BOOL (WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);
LPFN_ISWOW64PROCESS BBIsWow64Process = (LPFN_ISWOW64PROCESS)GetProcAddress(GetModuleHandle("kernel32"),"IsWow64Process");
pSettings->runningUnderWOW64 = FALSE;
if (BBIsWow64Process != NULL) BBIsWow64Process(GetCurrentProcess(),&pSettings->runningUnderWOW64);
if (pSettings->runningUnderWOW64) SendMessage(GetBBWnd(), BB_SETTOOLBARLABEL, (WPARAM)CONSOLE_INFORMATION_MESSAGE, (LPARAM)"64-bit Windows detected! (not officially supported but should work fine)");

ilmcuts

2008-12-31 04:04

Wow64DisableWow64FsRedirection unfortunately does not apply to this specific case.

tobbe

2010-08-31 16:05

ilmcuts posted a question about this on stackoverflow.com back in 2008. A year or so later someone posted a reply that might actually be what we need to solve this!

See http://stackoverflow.com/questions/386715/launching-shell-links-lnks-from-wow64 [^]

Quote:

> Anytime you here something is impossible on a computer, think again... The key is to utilize the c:\windows\sysnative\ path to shut off the redirection.
>
> Here is very simple code that will do what you want:
>
> #include <windows.h>
> #include <ShellAPI.h>
> #include <stdio.h>
>
> int main(int iArgc, const char *pArgv[])
> {
> ShellExecute(NULL, L"open", L"C:\\windows\\sysnative\\..\\..\\Program Files\\Internet Explorer\\iexplore.exe", NULL, NULL, SW_SHOWNORMAL);
> BOOL bIAmWow64 = FALSE;
> IsWow64Process(GetCurrentProcess(), &bIAmWow64);
> printf("I am a wow64 process: %hs\n", bIAmWow64 ? "Yes": "No");
> return 0;
> }
>
> I hope that is helpful.

I have not tested this. Someone with a 64-bit install of windows, please run the example code and report your findings.

alurcard2

2010-09-01 18:59

As I just posted on stackoverflow, the sysnative folder does nothing that Wow64DisableWow64FsRedirection doesn't.

Also, perhaps it should be pointed out that when there is no mirrored file in %programfiles(x86)%, nothing will happen.

The only fix I see for this, aside from compiling LiteStep and all modules into 64bit, is to add a special case for .lnk files in LSShellExecute and LSShellExecuteEx. We would have to parse the link file ourselves and then call ShellExecute with the data we parsed from the link. For ShellExecuteEx we should also set the out members of the original SHELLEXECUTEINFO struct afterwards.

108

core

minor

have not tried

2010-08-27 07:26

jugg

none

feedback

none

open

ShDocVw.ShellWindows / CreateObject("Shell.Application").Windows does not work

It is not possible to retrieve the list of windows from the shell using

ShDocVw.ShellWindows or CreateObject("Shell.Application").Windows

http://msdn.microsoft.com/en-us/library/bb774094%28VS.85%29.aspx [^]

core

major

always

2008-12-31 03:55

2010-08-16 03:10

ilmcuts

none

confirmed

none

open

64-Bit startup items are not run

On 64-Bit versions of Windows, some registry keys exist as separate 32-Bit and 64-Bit versions. Currently, LiteStep only parses those that are in the 32-Bit registry branch and consequently skips the 64-Bit keys.

Note that not all keys have two versions. In those cases, trying to access the 64-Bit version will just return the 32-Bit one.

It is also unclear what file redirection policy we need to apply.

ilmcuts

2009-02-28 06:10

A fix is in CVS. However, I'm not yet convinced that it's fully correct.

alurcard2

2010-08-16 02:53

Certain shortcuts in the "Startup" folder of the start menu won't run in Windows 7 64bit either. In my case, I have 4 items in %appdata%\Microsoft\Windows\Start Menu\Programs\Startup. 2 of them (Winamp and FastStone Capture, both 32bit apps) will run. However, Dropbox (32bit app) and TeamSpeak (64bit) will not.

alurcard2

2010-08-16 03:10

I forgot that I also have another app in %programdata%\Microsoft\Windows\Start Menu\Programs\Startup that wont run either. It's a 64bit app (ultramon) with one of those special shortcuts where you can't modify the "Target" property, and all the field says is the name of the app.

core

minor

always

2008-07-23 20:04

2010-08-14 02:27

xjill

none

confirmed

none

XP/2000/2003

open

Open Containing Folder in Search does nothing

In explorers search results view, choosing "Open Containing Folder" from the context menu while running LS does nothing. Launching the file, and viewing the actual folder path works as it should.

Do a file search in explorer, right click and choose "Open Containing Folder".

pirlouy

2008-12-25 12:53

This issue bothers me with audio software foobar2000. In contextual menu, there's a menu named "Open containing folder" which does not work and I think it's the same problem mentioned by xjill.

The foobar2000 team gives a clue: http://www.hydrogenaudio.org/forums/index.php?showtopic=67755 [^]
"Implement SHOpenFolderAndSelectItems properly"

jugg

2009-02-07 21:41

I can confirm this on Windows 2000 SP4. It makes no difference whether LSUseSystemDDE or LSSetAsShell is enabled.

alurcard2

2010-08-14 02:27

The "Open file location" option which essentially replaced this "Open containing folder" works fine on Windows 7

core

minor

always

2008-07-30 16:19

2010-08-14 02:24

alurcard2

none

confirmed

none

open

The "Status" page for network connections doesn't work while using litestep.

Trying to open the "Status" page in Control Panel -> Network Connections doesn't do anything while running LS.

It is possible to open it from the system tray however.

alurcard2

2009-01-02 15:38

It works fine while opening the explorer window from litestep(with LSUseSystemDDE enabled) or opening explorer by running litestep.exe c:\ or so. However, it doesn't work if you explicitly open explorer.exe and then navigate to the network connections page.

jugg

2009-02-07 21:36

I can confirm this issue on Windows 2000 SP4, what system was bug report based on?

Also to note, when LSUseSystemDDE is enabled, then accessing the Network and Dialup Connections in this method, allows the Status page to be opened:

!execute [$NetworkAndDialup$]

alurcard2

2009-02-08 11:34

The bug report was based on Windows XP SP3

alurcard2

2010-08-14 02:24

This does not seem to be a problem under Windows 7

core

minor

always

2009-01-12 07:30

2010-08-14 02:16

ilmcuts

none

confirmed

none

open

Folder Options cannot be opened from Control Panel

The control panel item "Folder Options" is broken when LiteStep is running. Clicking it has no effect.

jugg

2009-02-07 21:25

I can duplicate this issue on Windows 2000 SP4. What system was this bug originally reported for?

jugg

2009-02-07 21:33

When trying to open "Folder Options" appwiz.cpl is invoked. The only other item in the control panel that also invokes appwiz.cpl (afaict) is "Add/Remove Programs" and that works just fine.

alurcard2

2009-02-08 11:36

It doesn't work on Windows XP SP3 either. Of course going to Tools -> Folder Options in the menu will bring up the same screen and works just fine.

alurcard2

2010-08-14 02:16

This also doesn't work on Windows 7.

core

minor

always

2008-06-10 13:02

2010-08-14 02:06

alurcard2

none

confirmed

none

open

The "Find Target" button in shortcut properties doesn't work while using litestep.

The "Find Target..." button in shortcut properties doesn't work while using litestep.

Open the a shortcut properties and click "Find Target..." button. Nothing happens.

When clicking "Find Target..." a browse for file dialog should open up showing the location of the shortcut target.

ilmcuts

2008-07-23 16:22

IIRC, and I really may be wrong, it sends some messages either to Shell_TrayWnd or GetShellWindow(). I have no clue how to handle these though, but if you want to investigate, use Spy++ and possibly SetShellWindow.

alurcard2

2010-08-14 02:06

This problem does not exist on Windows 7, and therefore probably not on Vista either.

107

core

feature

always

2010-07-15 05:08

2010-07-15 05:09

MamiyaOtaru

none

feedback

none

CVS-trunk

open

handling additional case in trayservice allows correct positioning of vista+ icons

An unhandled case in trayservice is hit when the new icons ask for position info after, and independent from being clicked. Patch handles this case. More changes are needed in the various tray modules, but afaict, this change is needed in core.

Patch below, attaching it is failing. Is also here, in case the below gets mangled: http://www.sendspace.com/file/vqmoo3 [^]

diff -Naur ./litestepOld/TrayService.cpp ./litestep//TrayService.cpp
--- ./litestepOld/TrayService.cpp 2010-07-15 05:57:37.036467900 -0600
+++ ./litestep//TrayService.cpp 2010-07-15 05:58:02.711936500 -0600
@@ -459,6 +459,12 @@
                         }
                     }
                     break;
+
+ case 3:
+ {
+ lResult = pTrayService->TrayInfoEvent(pcds->cbData, pcds->lpData);
+ }
+ break;

                 default:
                     {
@@ -647,6 +653,37 @@
}

+LRESULT TrayService::TrayInfoEvent(DWORD cbData, LPVOID lpData) // size, data
+{
+ LRESULT lr = 0;
+ struct NOTIFYICONIDENTIFIER_MSGV1* s = (NOTIFYICONIDENTIFIER_MSGV1*)lpData;
+
+ //systemTrayNode *p;
+ //dolist (p, trayIconList)
+ // if (IsEqualIID(p->guidItem, s->guidItem))
+ // break;
+ //if (NULL == p)
+ // return 0;
+
+ //if (s->dwMessage == 1) {
+ // return MAKELPARAM(p->pt.x, p->pt.y);
+ //}
+
+ if (s->dwMessage == 2) {
+ return MAKELONG(16,16);
+ }
+
+ POINT p;
+ GetCursorPos(&p);
+
+ if (s->dwMessage == 1) {
+ return MAKELPARAM(p.x, p.y);
+ }
+
+ // somehow call this BOOL Tray::onWindowMessage( UINT nMessage, WPARAM wParam, LPARAM lParam, LRESULT &lResult )
+
+}
+
//=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
//
// HandleAppBarCopydata

diff -Naur ./litestepOld/TrayService.h ./litestep//TrayService.h
--- ./litestepOld/TrayService.h 2010-07-15 05:57:12.869085600 -0600
+++ ./litestep//TrayService.h 2010-07-15 05:57:52.080328400 -0600
@@ -28,6 +28,7 @@
#include "../utility/IService.h"
#include <ObjBase.h>
#include <vector>
+#include "WinUser.h"

// shell copy data types
#define SH_APPBAR_DATA (0)
@@ -39,6 +40,17 @@
#define ABP_NOTIFYSTATECHANGE (WM_USER+351)
#define ABP_RAISEAUTOHIDEHWND (WM_USER+360)

+struct NOTIFYICONIDENTIFIER_MSGV1
+{
+ DWORD dwMagic;
+ DWORD dwMessage;
+ DWORD cbSize;
+ DWORD dwPadding;
+ HWND hWnd;
+ UINT uID;
+ GUID guidItem;
+};
+
// data sent by shell via Shell_NotifyIcon
typedef struct _SHELLTRAYDATA
{

@@ -127,7 +139,10 @@
     LRESULT HandleAppBarCopydata(DWORD cbData, LPVOID lpData);
     LRESULT HandleAppBarMessage(PSHELLAPPBARDATA psad);

- // Handler for system tray notifications
+ // Handler for tray info event
+ LRESULT TrayInfoEvent(DWORD cbData, LPVOID lpData);
+
+ // Handler for system tray notifications
     BOOL HandleNotification(PSHELLTRAYDATA pstd);

     // Handler for LoadInProc messages

MamiyaOtaru

2010-07-15 05:09

oh god how did these get here I am not good with computer

(delete dupes please, I kept getting an error message from trying to attach file with initial report)

106

core

feature

always

2010-07-15 05:06

MamiyaOtaru

none

feedback

none

CVS-trunk

open

handling an additional case in trayservice for correct positioning of new vista+ trayicons

patch attached, affects trayservice cpp and h

104

core

feature

have not tried

2010-07-15 05:05

MamiyaOtaru

none

feedback

none

CVS-trunk

open

handling an additional case in trayservice for correct positioning of new vista+ trayicons

patch attached, affects trayservice cpp and h

103

core

major

always

2009-11-27 23:02

2010-05-04 08:54

Bektash

none

feedback

none

0.24.8

open

Unable to select Microsoft Live Mesh Options

I can see the Microsoft Live Mesh icon in the notification area, but right-clicking on the icon does not bring up the menu. I have installed LiteStep and Live Mesh on three computers and I have the same problem on all three.

jugg

2010-05-04 06:58

Please specify what Operating System and systray module and version you are using.

Bektash

2010-05-04 08:54

I am using Windows XP with the latest service pack and updates installed. I am also using xTray-2.2.2

core

feature

always

2009-03-05 15:23

2010-05-04 07:44

ilmcuts

none

feedback

none

CVS-trunk

open

Add fullscreen app notification

A notification such as a LM_FULLSCREENAPP message should be added to let modules benefit from the core's fullscren app detection code.

#define HSHELL_RUDEAPPACTIVATED (HSHELL_WINDOWACTIVATED | HSHELL_HIGHBIT)
(from winuser.h in recent PSDKs)

The core applies some additional logic upon receiving HSHELL_RUDEAPPACTIVATED before deciding that a full screen app has been detected. Modules currently need to reimplement this logic or use the original HSHELL_RUDEAPPACTIVATED notification and suffer from the same issues as 0.24.7.

Alternatively, the core could relay HSHELL_RUDEAPPACTIVATED only if its own logic indicates that a full scren app has been detected, thereby "fixing" HSHELL_RUDEAPPACTIVATED.

jugg

2010-05-04 07:44

I'm in favor of LM_FULLSCREENAPP over "fixing" HSHELL_RUDEAPPACTIVATED.

However, if each module starts defining its own behavior when a full screen app is active, the usability will become a mess.

101

core

major

always

2009-11-08 19:12

2010-02-03 15:49

alurcard2

none

feedback

none

open

WM_SETTINGCHANGE is not sent when the wallpaper slideshow changes wallpaper in Windows 7.

In Windows 7, desktop modules won't repaint their main windows automatically when the wallpaper changes. Something like this is required to avoid the old wallpaper staying.

case WM_SETTINGCHANGE:
    {
        if (wParam == SPI_SETDESKWALLPAPER)
        {
            RedrawWindow(hwnd, NULL, NULL, RDW_INVALIDATE | RDW_ERASE | RDW_UPDATENOW);
        }
        break;
    }

However, if you use the integrated wallpaper slide show the wallpaper is changed without any WM_SETTINGCHANGE message being sent so the old wallpaper remains unless you recycle or reload the desktop module.

When explorer is running, it seems to send the WM_SETTINGCHANGE message with wParam SPI_SETDESKWALLPAPER twice after the wallpaper has been changed.

It should be noted that desktop icon modules (Clickonic, IconDesk, xDesktop) need to repaint their windows when the wallpaper changes as well.

alurcard2

2010-02-03 15:49

Actually, on closer inspection, it seems like Explorer doesn't send WM_SETTINGCHANGE. However, Shell_TrayWnd seems to receive WM_USER+346 when the wallpaper changes. LiteStep's Shell_TrayWnd receives nothing when the wallpaper changes.

Seeing as the wallpaper still changes (if you unload any desktop modules) I don't think it's necessary to resort to a timer.

core

minor

always

2009-08-13 04:19

2009-11-19 20:38

gravity0

jugg

none

resolved

none

CVS-trunk

fixed

GCC 4.4 Fix (MathScanner.cpp)

When compiling with latest MinGW (gcc 4.4.0) build fails with error:
Missing declaration of 'EOF'

This is due to the cleanup of the standard headers in GCC 4.4.

This isssue can be resolved by adding:
#include <cstdio>

in MathScanner.cpp

jugg

2009-11-19 20:37

Fixed by include stdio.h

102

core

crash

always

2009-11-19 19:41

jugg

none

confirmed

none

0.24.8

open

GetLSBitmapSize crashes when passed a NULL pointer

GetLSBitmapSize() takes two pointers as parameters, and if passed NULL, it will de-reference the NULL pointer and crash.

call GetLSBitmapSize(NULL, NULL, NULL);

core

block

always

2007-10-09 12:30

2009-07-06 20:23

ilmcuts

jugg

none

closed

none

CVS-024x

fixed

LiteStep 0.24.8 - Release

This is a parent issue for all the issues that need to be fixed for 0.24.8.

This is just for issues that exist in the bugtracker. There are many more changes and additions in the actual code.

jugg

2007-11-06 13:16

Changing "Severity" to "block" since this is a "blocking" issue... ie. 0.24.8 can't be released until this issue is resolved.

jugg

2008-04-22 02:20

I'm leaning toward removing the Vista bugs from this release, and merging the relevant patches for the rest of the bugs back into the 024x branch, and releasing 0.24.8 off of the branch. The reasons are this:

1. hook.dll doesn't exist in HEAD. hook.dll has been part of the 0.24.x releases.

2. Win95 support should be dropped on HEAD, but 0.24.x should remain Win95 compatible.

3. Only Ilmcuts has Vista. I don't see a reason to hold a release up because only one developer can work on the issues.

4. We need to move to a new compiler, but all 0.24.x releases were done with VC6. So, 024x branch should remain supported by VC6, and HEAD should drop support for VC6.

5. Because this was the way it was originally planned.

I am happy to be the sole maintainer of the 024x branch. Everyone else can work on HEAD/ work on 0.25 release which simply can be support for Vista and whatever else. I'll manage the "legacy" 0.24.x branch and releases, of course anyone can contribute. If for some reason HEAD becomes release worthy sooner than later, there is no reason not to proceed quickly with a release off of the HEAD code base as well, but right now it is holding things up.

jugg

2008-04-25 14:50

As probably noticed, I've gone ahead and removed Vista changes from the 0.24.8 release. 0.24.8 will not be Vista compatible anymore than 0.24.7 is, i.e. it is not compatible with Vista.

I have updated the CVS 024x branch with all of the relevant changes for the 0.24.8 release excepting the Build date !about text patch and the Autohide modules patch.

No changes should be made to the the CVS 024x branch without first there being an issue and patch generated in the bug tracker. All new development should be done on HEAD first, and any relevant changes patched to the 024x branch if necessary in a controlled manner.

jugg

2008-05-29 14:33

This release is confirmed and in the pipeline for Release Candidate 1 pending all documentation updates and packaging preparation.

jugg

2008-06-02 11:20

0.24.8 Release Candidate 1 has been released. Any bugs found in RC 1, please add a releation ship for them as a child to this issue.

jugg

2009-07-06 20:23

not sure why this wasn't issue wasn't marked as closed... doing so now.

core

tweak

always

2007-10-14 07:04

2009-04-20 12:56

ilmcuts

none

feedback

none

0.24.7

open

External DLLs cannot be placed in module directory

If a module links to a 3rd party DLL, that DLL needs to be placed in our application directory. This is incompatible with NLM, among other things.

The underlying problem is that module DLL's directory is not part of the system's DLL search path. Only things like %path%, the application directory, system32, or the current directory are searched.

ilmcuts

2007-10-14 07:09

This can be solved by wrapping our LoadLibrary calls with SetDllDirectory on platforms that support it (XP SP1 and up). On other platforms, we can use SetCurrentDirectory instead. In both cases this requires that all LoadLibrary calls be serialized. This requirement can be softened if we only allow modules to be loaded from specific directories.

jugg

2007-11-06 13:20

Do we want to "solve" this? The litestep core has no concept of a "modules" directory. That is entirely an OTS specification.

xjill

2007-11-25 21:16

This could be useful regardless of whether there is a modules directory or not (as long as the module's elsewhere than app dir), so it's not like this would be some hack for OTS. It makes stuff easier for mod devs and keeps the app dir cleaner, but it might not need high priority. In the worst case scenario the module dev could figure out the dir on his own somehow.

ilmcuts

2007-12-23 17:48

Read that part of the summary as "the MODULE'S directory", not "THE module directory". All it means is that DLLs a module depends on can't necessarily live in the same directory as the module.

jugg

2008-04-25 11:46

Ok, how do we want to solve this?

It seems that any .dll a module might be linking against should be "shared" anyway, so placing the shared dll in the root litestep folder makes the most sense (although I am also a fan of keeping that dir clean). If we allow modules to keep system dlls or other dependencies in their folder, it would get messy since by using the convention of having a dedicated "modules" folder, one now no longer "knows" that xyz.dll in the folder is not a litestep module, but rather some module's dependency.

However, yes, I agree that in certain instances being able to load a module from an arbitrary location without copying all of its dependencies over to the litestep folder would be helpful.

As for the NLM issue, perhaps its time for an update to NLM, and not the core?

nochoa

2009-04-20 12:56

Perhaps I'm the odd man out, but if certain specifications specify a "module" directory, why can there not be a "Library" directory? How about a new option that is added to the core that allows you to specify an alternative path to search for DLL libraries? This path would then be added to the existing DLL search path.

ModuleLibraryPath c:\LiteStep\Libs\

It seems like a simple solution to an annoying problem, though I'm not sure how feasible this is.

core

crash

always

2009-02-13 13:58

2009-03-15 10:13

jugg

none

confirmed

none

0.24.7

open

litestep crashes on recursively included .rc files

The step.rc preprocessor "Include" statement allows recursively including files and thus crashes with a stack overflow

contents of step.rc:

Include other.rc

contents of other.rc:

Include step.rc

alurcard2

2009-03-15 10:13

I think the best way to fix this would be to block any include statement which ends up including the same file that contained the original include (looping). There is really no reason for anyone to set up their .rc files in that way.

core

feature

N/A

2007-10-09 13:31

2009-03-13 18:26

ilmcuts

none

resolved

none

0.24.7

fixed

Provide failsafe behavior in Safe Mode

Windows provides at least two mechanisms to repair 'corrupted' user accounts:
a) Safe Mode
b) the builtin Administrator account

At least in Safe Mode (a case can be made for the builtin Administrator as well) we should provide some failsafe behavior. Litestep may be the reason the user switched to Safe Mode in the first place - maybe a theme malfunctioned and left him with nothing but a blank screen or he couldn't figure out how to use or uninstall Litestep and went to Safe Mode to get rid of it.

Solutions are being discussed on the mailing list.

Evidence that people actually try to use Safe Mode or the Admin account for such purposes:
http://www.neowin.net/forum/index.php?showtopic=586521 [^]
http://abhimanyughoshal.blogspot.com/2006/04/pc-nightmare.html [^]
http://www.ls-universe.info/plugins/forum/forum_viewtopic.php?9685 [^] (?)

jugg

2007-11-06 14:34

How about adding "failsafe.cpp", and in the startup logic, if we are running in fail safe mode, jump execution to failsafe.cpp, which essentially creats its own msg loop, launches the recovery thread, and then performs the explorer shell launching routine. The purpose of this method, is so that we can modify the registry key, set explorer as shell, launch explorer, wait for TAKSBARCREATED msg to be posted, revert the shell setting to the previous value. Then present information via dialog or balloon tip explaining that litestep will be restored at the next reboot, unless they uninstall Litestep from add/remove programs. Or something along those lines.

My main points being:
1. move all code into seperate file to keep existing code untainted.
2. wait for taskbar created message before reverting the shell configuration.

ilmcuts

2009-03-07 11:04

Those are good ideas. I have submitted a separate report, Bug 96, to deal with them.

The only question left here is whether we want special behavior for the built-in Administrator account. I can see this as being somewhat useful, given that it is an emergency account. But note that recent Windows versions disable it by default (Vista, Win7 Beta).

If we implement this we should add a command line switch to force launching LS on that account. Installers could then ask whether to "force" LS or not.

jugg

2009-03-12 17:39

I'd be against not allowing LS to run under the administrator account. I use LS under that account, and afaik you can not pass command line options via the registry's shell setting.

ilmcuts

2009-03-13 18:26

I tend to agree.

Bug marked as "fixed". Further improvements will be discussed in Bug 96.

core

minor

always

2009-01-13 13:11

2009-03-13 18:08

ilmcuts

none

feedback

none

open

Balloon tip timeout value is not boundary-checked

The timeout value of balloon tips (in the tray in particular) has bounds - previous to Vista, balloons were shown at least 10 seconds and at most 30 seconds. See http://msdn.microsoft.com/en-us/library/bb773352(VS.85).aspx [^]

On Vista, the timeout is set to nine seconds. SPI_GETMESSAGEDURATION returns ERROR_NOT_IMPLEMENTED on Vista, but works on Windows 7, where it returns a value of five seconds (Beta 1).

LiteStep doesn't currently enforce any of this at all.

LiteStep is free to choose its own timeout value.

At the same time, all this should really be enforced module-side. However, given how few modules get balloons "right", some core assistance would be nice.

jugg

2009-03-12 18:53

Can you explain what you see the core providing here? Any systray module that implements balloon tips will already implement timeouts.

My systray.dll module has a minimum timeout of 5 seconds, a normal timeout of 10 seconds, and a max of 30 seconds, which is inline with 2k/xp as you linked in your report. I've also considered pulling those limits into step.rc configuration settings. Anyway, given that the only other systray module that implements balloon tips is xtray (which is broken) I'm uncertain how to take the "how few modules get balloon tips right" statement...

I can not see what the core could provide to improve this. So, please explain what the intention of this report is, as it seems to me it should be closed without change.

ilmcuts

2009-03-13 18:08

I really wanted to ask whether LS should boundary-check the uTimeout value before the LSNID is sent out to modules, but figured that a more open-ended question might elicit better ideas.

The statement about modules not getting balloons right was aimed at just that - there are a number of tray modules (systray2, vtray, xtray, systray just off the top of my head), but only one has proper and another one has somewhat broken support for balloons. That's a really poor quota for a feature that's been around since Windows 2000. Because of that I felt that providing some help might make more modules support balloons *properly*.

Thus, an argument can be made that uTimeout should be boundary-checked core-side (or that some other step should be taken core-side) because it's such a small detail that I don't think it will get any attention by module devs if they're still stuck trying to provide even basic balloon tip support. Most likely, they'll just take the existing timeout value (which is uTimeout) and use that without further adjustment.

EDIT: Ontop of that, the default "system" timeout depends on the Windows version, making it virtually impossible for modules to get it "right" at all times. That is, unless LiteStep defines its own timeout value of course.

core

feature

always

2006-05-04 15:42

2009-03-12 18:59

phil

none

feedback

none

CVS-trunk

open

Logging, please!

Logging is very handy to diagnose various failures in LS. The ideal logging system would do some of the following :

- Disable message boxes of severity less than or equal to the current logging level. Top logging mode would disable all message boxes.
- Provide similar, more informative error information stemming from RC code issues (e.g. conditionals)
- Export the logging implementation for use by external modules.

jugg

2006-05-06 20:22

I agree, we need to have better logging support. This is definitely something we are looking to add into the next major release (off of CVS-trunk). However, we need to discuss if there is any level of support we want to add back into the 0.24.x series. Anyone have input?

phil

2006-11-11 14:18

Given the general lack of progress on this, and the rather limited community effort for complex themes, maybe this is unwarranted. If more people were developing more heavily engineered themes this would be more of an issue. They aren't; it's probably not worth the developer time to implement logging.

phil

2006-11-11 14:19

s/progress/feedback

ilmcuts

2007-07-23 11:45

A logging API shouldn't show message boxes in the first place.

alurcard2

2009-01-10 17:58

This is definitively something that would that would improve the overall experience with LiteStep. Some configurations/modules will throw excessive amounts of message boxes when something goes wrong horribly wrong (variables which aren't set, some other module didn't load, the themer failed to include a .rc file, etc...).

However, I still think that there is a need for some message boxes(it should be optional though). For things such as bang commands failing, to notify the user that something they just did failed.

I think a log section in the !about window could be neat, as well as a LiteStep.log in the LiteStep directory.

jugg

2009-03-12 18:59

The logging facility should not provide a UI. However, another interface may/should be implemented that can be used to monitor the log, and based on some configuration, do something in response to a log event. Such a montior system should be implemented independently, and certainly would not have to be part of the core.

core

minor

always

2009-03-11 08:50

2009-03-11 10:03

jimrandomh

none

feedback

none

open

XP user switching screen does not show number of tasks

When Explorer is used as the shell, the XP user switching screen (accessible with Win+L on some but not all configs) shows the number of programs running (actually the number of task windows). If LiteStep is used as the shell, the number of programs running is not shown (It just says "Logged on", which is the same thing it says if there are zero tasks running). If there are multiple users logged on simultaneously, then users who use Explorer have the number of programs running shown, while users who use LiteStep do not.

core

feature

always

2009-03-07 10:39

2009-03-07 10:40

ilmcuts

none

feedback

none

open

Improve Safe Mode behavior

As per jugg's suggestion in response to Bug 33:

In Safe Mode, LiteStep currently launches Explorer and exits silently. Instead, it could wait for the TaskbarCreated message and show a "dialog or balloon tip explaining that litestep will be restored at the next reboot, unless they uninstall Litestep from add/remove programs."

Any such code should be implemented in a separate "failsafe.cpp" file.

core

feature

N/A

2009-01-29 12:38

2009-03-07 06:14

jugg

none

feedback

none

open

Add "About LiteStep" and "Switch to Explorer" options in recovery menu

I think it would be applicable to have an "About LiteStep..." entry in the recovery menu.

I think it would be benefitial to have "Switch to Explorer" entry in the recovery menu to help people restore their desktop. This should probably use the same code iplemented in the -explorer command line switch.

ilmcuts

2009-03-07 06:14

I like both suggestions. The "switch to explorer" feature is slightly tricky, however, as we need to shut down all shell services (Shell_TrayWnd in particular) and only then can launch explorer. It's not simply a !bang or such but an entirely new process exit code path.

core

feature

N/A

2009-02-23 15:55

2009-03-05 15:26

Delf

none

closed

none

CVS-trunk

won't fix

FullScreen app EVENTS

LSOnFullScreenAppFocus !BangToFire <number of screen>
LSOnFullScreenAppUnFocus !BangToFire <number of screen>

Those to be fired if defined. No matter the value set for LSAutoHideModules
For people who know which module to hide and want to preform more actions than just hiding modules, perhaps destroying labels or making changes to other screens like repositioning elements into other screens.

jugg

2009-02-23 17:39

In the future we will be adding an LM_FULLSCREEN message that modules can register for to be notified of full screen windows. When that happens the requested functionality could be handled by a module, however such functionality most likely not be added to the core.

jugg

2009-02-23 17:40

Do note, that appbars always receive notification of fullscreen changes, and as such a module could currently receive such notifications if it was an appbar.

Delf

2009-02-26 08:49

Since I'm only a "themer" and not a "coder" (yet). My feature request seems pretty much denied.

Thanks for the LM_FULLSCREEN message, I might use it once I've learned a bit coding if I don't simply write a patch that adds the features i requested.

ilmcuts

2009-02-28 05:22

Take a look at systemevents.dll.

ilmcuts

2009-03-05 15:26

The proposed event triggers can be implemented module-side once Bug 95 is resolved.

core

minor

always

2007-10-14 07:15

2009-03-05 15:16

ilmcuts

none

feedback

none

0.24.7

open

Race condition if modules set error mode

In Module::_LoadDll() is first SetErrorMode to temporarily reset the process error mode to 0. After the following LoadLibrary call, the error mode is reset. This is a race condition if this happens on several threads.

If thread A first calls SetErrorMode(0), then thread B does the same, thread B will receive '0' as the previous mode. If thread B reaches the second SetErrorMode line last, '0' will be set permanently.

ilmcuts

2007-10-14 07:17

The fix is to serialize the SetErrorMode/LoadLibrary/SetErrorMode block, and to make sure that any initModuleEx only runs once all of the above blocks are done.

jugg

2008-08-18 10:46

The overhead to "fix" this isn't very likable. The fix would just be another patch added to the mess that is our threaded module implementation. We need to get rid of the threaded modules, not keep trying to patch the broken implementation.

Essentially the fix would consist of:

UINT uOldMode = SetErrorMode(0);

_WaitOnAllModuleInit();

m_hInstance = LoadLibrary(m_tzLocation.c_str());

_WaitOnAllModuleInit();

// Second, restore the old state
SetErrorMode(uOldMode);

Where "_WaitOnAllModuleInit() would spin until any currently loading threaded modules finished their init routines.

Implementing _WaitOnAllModuleInit() would be slightly messy, but doable. I just don't see the worth in benefit vs effort for this edge case issue.

The reason you can't do your suggestion to serialize the calls is because of:

bool Module::Init(HWND hMainWindow, const std::string& sAppPath)
{
    ASSERT(NULL == m_hInstance);

    // delaying the LoadLibrary call until this point is necessary to make
    // grdtransparent work (it hooks LoadLibrary)
    if (_LoadDll())
    {
...

core

minor

always

2009-01-28 16:07

2009-03-05 15:07

jugg

none

feedback

none

0.24.7

open

It is not possible to use a litteral '$' dollar sign in a step.rc text string parameter

When trying to include a dollar sign character '$' in a text string configured in the step.rc, the dollar sign is stripped from the retreivable text. Even worse is when there are two dollar signs in the text string, the text inbetween it interpreted as an e-var, and an error is displayed about an undefined variable

Example1:
---------
define in the step.rc:

Money "$1,000,000.00"

Then execute:

!alert "I have $Money$!"

The incorrect output is:

Hello I have 1,000,000.00!

Example2:
---------
define in the step.rc:

PaymentDue "$5.00 of $100.00"

Then execute:

!Alert "You owe $PaymentDue$"

Produces an error box output:

Error in Expression:
5.00 of

Description:
Syntax Error: Expected END, but found ID

Followed by the !alert dialog's incorrect output:

You owe 100.00

The apparent problem is that VarExpansion removes all dollar signs $ even if it did not successfully expand the value. This seems fully incorrect when there is only a single $. And when there is two $, it would see that expansion shouldn't occur if the contents between the two $ don't evaluate to a valid expression, but instead is just a simple string. Whitespace can not be within a step.rc directive, so why should it be allowed in an e-var which represents a step.rc directive?

tobbe

2009-01-29 01:34

I think the way to solve this is to add some kind of escape character.

By only outputting the dollar sign in case no evar expansion can be found you'd run in to problems if you want to output something surrounded by dollar signs that also is an evar. Example:

This is the wanted output: This is a $test$

;------------------------
test asdf

!alert "This is a $test$"
;------------------------

This is the actual output: This is a asdf

Maybe something like this?

!alert "This is a $test$" --> This is a asdf
!alert "This is a $$test$$" --> This is a $test$
!alert "This is a $$$test$$$" --> This is a $asdf$

jugg

2009-01-29 13:09

If it is the case that a single $ is not allowed, then I'd expect that rather than the $ being stripped, the remainder of the string is truncated.

In such a case !alert "I have $1,000,000" should return: I have

It should not return: I have 1,000,000

However, I see no reason to complicate things. The parser can very easily be made to just return the requested string unmodified if it couldn't be successfully expanded into anything. Adding in escape handling for $ would be a bit more involved.

Of course having the parser distinguish between an undefined evar, and an non-evar would be the concern, which is why I mentioned the whitespace issue... No Directive can contain whitespace, so $My String$ obviously can not be a valid variable expansion. But $MyVar$ should always be considered a variable expansion, even if MyVar is undefined - thus produce a failed expansion.

crazy2be

2009-02-19 18:39

Sofaras i know, there is also no way to:
- insert a literal newline/linefeed
- insert a literal "
- break up input of a variable onto multiple lines

My suggestion for this would be to follow the normal C/C++/C#/Javascript escape codes, with \n, \", \$, and ending a line with a \ causing the variable to include what is on the next line in it's definition aswell.

The problem with this solution is that it'll make it so that all paths must use double backslashes, rather than a single backslash, more or less obsoleting all themes.

core

minor

always

2007-11-06 13:45

2009-03-05 15:06

jugg

none

feedback

none

Windows

2000 Professional

SP4

CVS-trunk

open

ABM_GETTASKBARPOS returns incorrect information

ABM_GETTASKBARPOS should return the position of the TaskBar not the SystemTray.

We currently return the position of the systray, because most applications that are using ABM_GETTASKBARPOS, are interested in the general location of the systray. However, when using ABM_GETTASKBARPOS under Explorer, the rectangle that is returned is of the entire taskbar, not just the systray.

There are some applications that use ABM_GETTASKBARPOS when creating their own AppBar to determine their default size and position (which is always at least screen width or height in size under Explorer). However, under Litestep the systray is relatively small, and therefore these applications end up with a rather small window, which doesn't stretch across the entire screen, as the application is expecting.

core

minor

always

2009-01-03 11:22

2009-03-05 15:05

ilmcuts

none

confirmed

none

open

LS desktop does not interact with Vista's new ALT-TAB

1) Vista's new ALT-TAB dialog includes (large) thumbnails in addition to icons. If LiteStep is running, it does not show a thumbnail for its special "Desktop" entry but only the (apparently generic) "Desktop" icon.

2) Selecting the "Desktop" entry in the dialog does nothing.

testdesktop.7z (27 KB) 2009-01-10 15:44

jugg

2009-01-03 18:10

Can you provide class name and window hierarchy information for the Vista desktop please? Is it still a descendant window of Progman?

ilmcuts

2009-01-09 13:40

It's SysListView32 / "FolderView". The hierarchy looks like this:

Desktop
-> Progman / "Program Manager"
---> SHELLDLL_DefView / ""
-----> SysListView32 / "FolderView"
-------> SysHeader32 / "" (invisible)

which I believe is the same as before.

ilmcuts

2009-01-16 15:32

Replicating Explorer's window hierarchy makes the thumbnail work.

ilmcuts

2009-03-05 15:05

No longer a "mystery bug" because we should be able to work out a fix now.

core

tweak

always

2009-03-05 15:01

ilmcuts

none

feedback

none

CVS-trunk

open

Message loops should call CallMsgFilter

All message loops should call CallMsgFilter. This simplifies thread message handling and leaves fewer opportunities for subtle bugs.

Among other things, this enables modules to inject IsDialogMessage calls onto the main thread as needed.

core

tweak

always

2009-03-05 14:58

ilmcuts

none

feedback

none

CVS-trunk

open

Remove 'threaded' module flag

Support for "threaded" modules should be dropped. Loading modules in their own thread offers little to no benefit. Instead, it much complicates the core code and makes it almost impossible to correctly implement !bang handling, among other things.

Modules are still free to create their own worker threads. This makes much more sense than forcing an entire module into a separate thread, as the module knows best when and for what purpose it needs a thread.

This does not necessarily (but could) imply removing support for calling the LiteStep API from threads other than the main thread.

core

minor

always

2007-07-13 16:54

2009-03-05 14:44

jugg

none

feedback

none

Windows

2000 Professional

SP4

0.24.7

open

Startup items are not synchronized with the shell initialization correctly

Startup items after RunOnce should be loaded after the shell user interface is fully loaded. Currently we run all startup items before we load modules (user interface). Therefore, we need to run the StartupRunner in its own thread with synchronization events to ensure ModuleManager is done before continuing StartupRunner.

--------------------------------------------------------------------------------
Startup Order according to MSDN
- http://support.microsoft.com/support/kb/articles/q179/3/65.asp [^]
--------------------------------------------------------------------------------
All keys are supposed to load asynchronously, except for

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

which is run synchronously.

The system loads the RunServices(Once) keys (under 9x)
--------------------------------------------------------------------------------

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices

<Logon Prompt>

<Shell loads, startup/initialization routines>
<Shell begins running startup items>

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

<Shell loads user interface>

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

StartUp Folders ( I guess All users first, then Current User )

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

--------------------------------------------------------------------------------

jugg

2008-12-27 13:55

http://blogs.technet.com/markrussinovich/archive/2005/07/24/running-windows-with-no-services.aspx [^]

"There will be a delay before Explorer redraws the desktop because it waits for the Service Control Manager (SCM) to signal the ScmCreatedEvent, which Services signals during its initialization"

core

major

always

2008-06-02 11:17

2009-03-05 14:42

jugg

none

confirmed

none

open

LCReadNextCommand/Config/Line implementations are broken.

LCReadNextLine() should itterate over each and every line in the RC file.

LCReadNextCommand() should itterate over each and every line *NOT* starting with a reserved character - specifically the * character.

LCReadNextConfig() should itterate over each and every line starting with the * character that matches the pszConfig parameter.

All three functions should return the entire unparsed line including the key name.

Key1 "hello1"
Key2 "hello2"
Key3 "hello3"
*Key4 "goodbye1"
*Key4 "goodbye2"
*Key4 "goodbye3"

Calling LCReadNextLine() six times would return successfully all six entries.

Calling LCReadNextCommand() six times would return successfully three times and fail three times. The first three times would return the lines with hello1, hello2, and hello3 entries.

Calling LCReadNextConfig() six times with "key4" as pszConfig param, would return successfully three times and fail three times. The first three times would return goodbye1, goodbye2 and goodbye3 entries.

I believe the last time this was implemented correctly was in 0.24.5 (or 11-23-99 build) before the rewrite into COM implementation. 0.24.6+ lost this functionality.

Our current SDK documentation correctly documents:
LCReadNextLine
LCReadNextConfig

And incorrectly documents:
LCReadNextCommand - it says the function is deprecated, and does not specify that it skips lines that begin with an * or any reserved character.

jugg

2008-06-17 08:51

I've updated the issue with more detail. The main functionality missing from the code is that LCReadNextCommand does not skip lines that LCReadNextConfig retrieves. Basically meaning that LCReadNextCommand should skip all lines beginning with an * character. Also, LCReadNextConfig currently does not enforce that pszConfig begin with a * character. It should.

Also, the documentation for these functions state that they should return the entire line, unparsed. However we currently expand $evar$ expressions. Also, the 11-23-99 source code also expanded $evar$ expressions. So, while I think the documentation should be the correct behavior, it seems that it is not, and the documentation should be changed in that regards.

ilmcuts

2009-02-28 05:29

At this point there likely are many modules that depend on the current behavior. If we need the different behavior we should add a new function.

By the way, the major offender wrt multiple setting lines not starting with a * character is the core with its "LoadModule".

jugg

2009-03-05 00:34

In my testing I've only found a few modules that are using LCReadNextConfig() incorrectly. So, fixing LCReadNextConfig() would force those modules to conform to expected conventions (ie. multiple settings of the same name must have a '*'), but as such it would cause those modules to diverge from their documentation. However, it would not "break" the modules, since with the fix in place the offending setting would simply need to be prefixed with a '*' in the user's config; it would break existing users configurations (ie. the user configurations would have to be updated to place a '*' in front of the offending settings).

Fixing LCReadNextCommand does not break any module that I'm aware of.

As such I've committed changes to CVS HEAD that fix LCReadNextCommand, and conditionally fix LCReadNextConfig (see buildoptions.h new define: LS_COMPAT_LCREADNEXTCONFIG)

I've also added support for using *LSLoadModule rather than the traditional LoadModule, this also is controlled via buildoptions.h with LS_COMPAT_LSLOADMODULE. However, LoadModule would still work even with LCReadNextConfig fix enabled. We should probably change this to support both *LSLoadModule and LoadModule at the same time for a transition period before forcing *LSLoadModule.

I am not marking this issue as resolved yet, because I think this warrants further discussion and testing to ensure these changes do not trully break prevelant modules. If it appears that this does break things beyond repair, these changes can obvsiouly be undone.

core

major

always

2008-05-12 18:41

2009-03-05 14:41

jugg

none

confirmed

none

CVS-trunk

open

expansion of $e-var$ does not expand to the full value of the e-var

When calling VarExpansionEx(), the result does not contain the entire value of the variable as it was defined.

step.rc:
--------
MyEVar Hello World!
MyEVar2 "Hello Again World!"
MyEvar3 "Hello World" "Goodbye World"

Or instead of defining them in the step.rc, do it programatically:

LSSetVariable("MyEvar", "Hello World!");
LSSetVariable("MyEvar2", "\"Hello Again World!\"");
LSSetVariable("MyEvar3", "\"Hello World\" \"Goodbye World\"");

code:
-----
char tmp[128];
VarExpansionEx(tmp, "$MyEVar$", 128);

Inspect the contents of "tmp" and it will contain "Hello" without the quotes.

char tmp[128];
VarExpansionEx(tmp, "$MyEvar2$", 128);

Inspect the contents of "tmp" and it will contain "Hello Again World!" without the quotes.

char tmp[128];
VarExpansionEx(tmp, "$MyEvar3$", 128);

Inspect the contents of "tmp" and it will contain "Hello World" without the quotes.

This needs to be handled with care as any change will likely affect/break many existing modules and configurations.

jugg

2009-01-29 13:32

Hopefully a better example as to why this is an issue:

For a module using GetRCColor("ModuleBGColor", defClr);

This is valid step.rc syntax:
ModuleBGColor 255 128 128

But this is invalid step.rc syntax:
ModuleBGColor "255 128 128"

Yet with the current implementation this is required:
ThemeBGColor "255 128 128"
ModuleBGColor $ThemeBGColor$

Which just isn't very consistent. So to summarize, an $evar$ just should *not* be forced to be a quoted string value.

Any ugly hack, which I don't like nor want to implement, but which does provide a way around this without breaking compatibility:

ThemeBGColor 255 128 128
ModuleBGColor $rcLine(ThemeBGColor)$

Which could perform a raw substitution, rather than a string substitution. rcLine() can be renamed to something better(?), perhaps: directive()

core

major

always

2008-05-12 18:30

2009-03-05 14:41

jugg

none

confirmed

none

CVS-trunk

open

LSGetVariable() does not return value set by LSSetVariable()

When calling LSSetVariable with an unquoted value containing whitespace, subsequently calling LSGetVariable only returns the first "word" of the value.

char tmp[128];
LSSetVariable("myvar", "test value");
LSGetVariable("myvar", tmp);

Inspect the contents of "tmp" and it will only contain "test" (without the quotes).

char tmp[128];
LSSetVariable("myvar", "\"test value2\"");
LSGetVariable("myvar", tmp);

Inspect the contents of "tmp" and it will contain "test value2" (without the quotes)

In both instances the result is incorrect.

The solution will likely affect many modules and configurations. This needs to be handled with care.

jugg

2008-08-20 11:23

Another aspect to this issue is that $evars$ are expanded... they should not be. We need a complete "raw" access API set to our configuration data. Right now, LSGetVariable is no different than GetRCString(). And if we only fix the quote issue, it will be no different then GetRCLine(). LSGetVariable() should not expand $evars$ or touch the value in anyway. What comes out of LSGetVariable() should be identical to what goes into LSSetVariable(). Example:

char tmp[128];
LSSetVariable("myvar1", "Hello World");
LSSetVariable("myvar2", "$myvar1$");
LSGetVariable("myvar2", tmp);

tmp should contain literally: $myvar1$

With the current broken implementation, it would only contain: Hello

That is pointless/worthless.

core

minor

always

2007-06-26 19:25

2009-03-05 14:40

jugg

none

confirmed

none

0.24.7

open

TrayService Shared Icons are not implemented fully/correctly

The TrayService does not implement shared (linked) icons correctly. When shared icons are created, they should be linked together. Then, when the "parent" icon is updated, any "child" icon should be updated as well.

The current code has some basic icon sharing (ensures that a shared icon will correctly be displayed initially, but does not get updated correctly).

core

major

N/A

2006-11-06 15:03

2009-03-05 14:37

jugg

none

feedback

none

Windows

2000 Professional

SP4

CVS-trunk

open

TCHAR/char mix-match throughout code base

The entire code base is fairly riddled with mixing of TCHAR/char and LPTSTR/char* data types. While this allows the code to build normally (SBCS), it would not allow it to be built for MBCS or Unicode. Not to mention it just looks ugly.

jugg

2008-04-25 11:35

We need to decide if we want to be able to compile the core as UNICODE or not. Do we move to unicode only, or use TCHAR to be able to build both, or stay with what we have and clean up the code base to not use TCHAR mappings at all?

jugg

2008-05-16 12:43

Should we move to Unicode only, creating conversion routines in our API so existing modules continue to work (but have to drop win9x support)? Should we just strip out all of the TCHAR mess and stay with ascii implementation? I kind of think that if anyone ever takes Litestep to 64bit, that would be the time to change to unicode. Otherwise, just stay with ascii.

I went through this with PureLS, and made PureLS UNICODE (using tchar mappings), and it worked great. I didn't provide conversion routines in the API, so modules had to be recompiled. Recompiling modules was a chore, but very doable, the caveat being those modules without source code.

Acidfire

2008-05-16 14:32

I think we should convert everything to TCHAR and such. Going back to ascii would be a major step backwards.

When everything uses TCHAR's we can choose to compile as ascii or unicode. Like jugg said, if a 64bit build comes it could be built in unicode, which would take no effort if all the code already used TCHAR's.

jugg

2008-05-17 16:01

Sounds good to me. It is a lot of work though. It is not necessary (nor correct) to turn everything into TCHAR or wchar. We need to define what parts of the code base should be TCHAR mappings, what parts should be wchar, and what parts should be char.

Off the top of my head my thought is that the API should remain char types to keep module compatibility. We can add wchar variants that modules can be compiled against.

The step.rc we've discussed to move to utf-8 previously...

Use of the Win32 API should be TCHAR mappings.

Or we could just do a complete TCHAR conversion, everything is char or wchar with no concerns for compatibility.

ilmcuts

2008-07-19 12:26

My opinion is as follows:

* Two supported build types: 32-Bit ANSI and 64-Bit Unicode (IF we start supporting a 64-Bit build).

* New APIs should be added with A and W versions.

* I'm not sure what to do about the existing lsapi.dll exports, to be honest. Keeping them ANSI would maximize source compatibility so I'm voting for that currently.

* The internal code base should be TCHAR (past checkins labelled 'TCHAR fixes' were aimed in that direction).

That enables all permutations of 32-Bit/64-Bit and ANSI/Unicode builds. Quite obviously, the Unicode builds wouldn't work on Win9x. I don't think we should even try to support MSLU (unless it turns out to be really trivial).

jugg

2009-02-23 22:52

Obviously the unicode builds wouldn't work on win9x if they are 64bit.

As for API being unicode or ansi... I think we should move all API to tchar mappings, or create W versions for the old API so that modules written for 64bit and unicode can actually be fully unicode without having to do a bunch of internal conversions for using the old ansi API.

I don't see the point in providing "source compatibility" for 64bit modules if it prevents them from being fully unicode. Why provide a 64bit unicode core if the modules can't be unicode as well? I can understand (to a degree) providing the existing ansi exports in a 64bit unicode build, but unless we also provide equivelant unicode exports, then I don't understand the point.

core

block

always

2009-03-05 14:36

ilmcuts

none

feedback

none

open

LiteStep 0.26.0 - Release

This is a parent issue for all the issues that need to be fixed for 0.26.0.

This is just for issues that exist in the bugtracker. There are many more changes and additions in the actual code.

However, please try to track all changes that are more than just cleanup work.

core

major

always

2006-04-26 15:11

2009-02-28 16:27

phil

jugg

none

closed

minor fix

none

CVS-024x

fixed

$expressions$ always calculate as floats. Compatibility issue with 0.24.7 that provided ints.

Math evaluation of integers currently return a float value causing compatibility problems with 0.24.7 based step.rc and modules. If a module is expecting to read an integer parameter, it may not know how to interpret a float value.

something like :

myVar1 "18"
myVar2 "13"

will cause $(myVar1 - myVar2)/2$ to report 2.5 instead of 2 (as provided by integer()).

MathValue.cpp.patch (1 KB) 2006-05-03 12:52
MathEvaluateString.patch (2 KB) 2006-05-23 19:19

jugg

2006-04-26 15:19

Because we are requiring step.rc compatibility on the 0.24.x branch, we need to default the evaluation behavior to return integers instead of floats. This probably requires us to add an additional function float() like the existing integer().

A simple example:
$3/2$ = 1.5 in CVS-24x
$3/2$ = 1 in 0.24.7

jugg

2006-04-26 15:28

We may want to look into adding support to analyze the format of the expression, so that be default:

$3.0/2$ = 1.5

but

$3/2$ = 1

However, if this is added complexity to the code base, then as previously stated we should just default to integer results, and use a float() function to return a float value.

If so, how should this be evaluated?
$(3/2)*2$ = 2 or 3?

phil

2006-05-03 11:59

Is there an obvious place in the code to fix this ahead of an officially sanctioned patch? :)

jugg

2006-05-03 12:59

The attached patch (05-03-06 12:52) is a temporary hack. Anytime a number mathvalue is converted to a string, it is cast to an INT.

ilmcuts

2006-05-04 05:18

If we want to remove the hack in 0.25.x or so we could wrap this in an #ifdef LS_COMPAT_xxx (see buildoptions.h). Or would you just apply this to the branch? In this case we need to document the change in a trunk readme, else we'll forget about the difference in behavior sooner or later.

jugg

2006-05-04 10:08

The (05-03-06 12:52) patch is not to be applied to CVS in anyway. It is a temporary solution for anyone looking at this bug report and needs a fix before we can produce the correct solution (whatever that may be).

jugg

2006-05-23 19:30

The new patch "MathEvaluateString.patch" (05-23-06 19:19) is another take at the fix. This one creates a new MathValue member function "ToIntegerString()" and duplicates 0.24.7 behavior. The problem with this patch is that $evar$ expressions will not be evaluated to anything but an integer value (ie 0.24.7 behavior). This removes the large benefit of 0.24.8 being able to evaluate and return strings and other types in $evars$.

We could track a private member variable in MathValue which determines how to format the data returned by the original ToString() member function. This variable would be set anytime a 0.24.8+ MathFunction is called. When set, the default ToString behavior is used, otherwise if not set, it means compatibility needs to be retained, and ToIntegerString behavior should be used.

Or we could have a new step.rc directive "LSEnableAdvancedEval" or something which enables the behavior.

jugg

2006-11-07 16:36

Ok, I've come up with a solution that I think works. At least the themes I have tested now with my new code, appear to work as well (or as bad) as they did in 0.24.7.

I created a function in MathEvaluate.cpp called MathEvaluateCompatibleString() which uses another new function in MathValue.cpp called ToCompatibleString().

Then internal to VarExpansionEx(), MathEvaluateCompatibleString() is now used in place of MathEvaluateString().

The relevant detail that makes this work is that MathValue::ToCompatibleString contains this:

// To keep compatible with 0.24.x math evaluations, we must
// return an integer formatted string for all number type
// results. Thus, convert number value to an Integer prior
// to returning it as a string.
if(NUMBER == mType)
{
    ostringstream stream;

    stream << ToInteger();

    return stream.str();
}

// All other values, let the default handler deal with the
// conversion process.
return ToString();

The rational is this: Since the 0.24.7 conditional parser only supported integer values, all previous themes/modules would only being doing integer comparisons, thus in the current release any Number value should be converted to an Integer for compatibility reasons. Beyond that, any other value type is new, and therefore is not bound by compatibility rules, and can be treated as normal.

There is another semi-related compatibility issue as well. In 0.24.7 If/ElseIF comparisons would treat undefined variables as a Zero. Thus a comparison of:

If 0=UndefinedVar
Endif

would be evaluated as true, since "UndefinedVar" evaluated to "0", so 0=0. In the current experimental releases, that condition would evaluated to false, since internally the comparison would be 0="Undefined" which is not equal.

I have created a fix for this as a flag to MathEvaluateBool() "MATH_AS_ZERO_ON_UNDEFINED". This allows the If/ElseIf conditional parser to call into the Math Parser with that flag and have comparisons work like the previously did. Personally, I would rather make people fix their themes, but nothing sucks worse than putting out a new release and a bunch of newbs who are using the broken themes suddenly don't have a working desktop.

Thoughts?

phil

2006-11-11 14:13

The un/defined change seems valid. I don't expect LDE(X) to break, for example - we tend to check for existence rather than specific value.

It should be a quick fix for any broken theme. I haven't tested LDE(X), however.

jugg

2007-01-22 23:45

I have committed a fix to CVS. It is a slight re-work of my last note. Instead of creating a new interface function of MathEvaluateCompatibleString(), I created a new flag MATH_VALUE_TO_COMPATIBLE_STRING which is passed to MathEvaluateString(). If this flag is set, MathValue method ToCompatibleString() is used instead of ToString().

As for the second issue being discussed (undefined variable != 0), it will be left as is. If anyone is concerned about that, please open a separate bug report to track the issue.

core

minor

always

2006-03-09 16:38

2009-02-28 16:26

jugg

none

closed

none

Windows

2000 Professional

SP4

0.24.7

fixed

Platform evars are only set to true, never false

Platform specific evars are only set to true for the platform that Litestep is running on. e.g. $Win95$ = TRUE when running on Windows 95, however $Win98$ or $WinNT$ or any other platform variable is then left undefined, instead of being initialize to false. This causes inline evaluations of evars to cause error MessageBox when using these variables that are documented to exist.

execute from lsxcommand:

!alert $Win98$

When on a different platform than Windows 98 this will produce an undefined variable error message.

Using and undefined variable in IF/ELSEIF file parser directives does not cause an error.

Because the variables are documented to exist, the core should ensure that they are defined and initialized to the correct states.

phil

2006-04-19 15:22

I think this is standard behaviour, as we noted in #lsdev. You simply need to nest variables somewhat defensively.

It would be helpful to be able to selectively suppress error boxes with filters, but I'm not sure if that is possible.

jugg

2006-04-20 14:43

This may not be valid, since to retain 0.24.7 step.rc compatibility, the expression:

IF WIN98
ENDIF

Should evaluate to FALSE. However in 0.24.7 if WIN98 was set to "0", that expression would then evaluate to TRUE because WIN98 was defined.

phil

2006-04-25 03:32

That is as I would expect, unless I am misunderstanding you.

Simply put, as I understand it:

If WIN98
EndIf

will only be inactive if WIN98 is not defined anywhere. Otherwise, irrespective of the value of WIN98 ($WIN98$), this conditional would trigger. You can filter against (numeric) values of WIN98 via :

If WIN98 = 0
EndIf

For the casual reader: Note that string comparisons remain unavailable, sadly, despite being planned for the ancient 0.24.6 release. As such, you need to workaround these kind of things with a partner variable of numeric value.

Defining a variable with no value :

MYVAR

will create a boolean (with value of TRUE, also mapped as 1 IIRC). Sadly, you cannot 'kill off' a variable once it has been defined in any way.

phil

2006-04-25 03:34

In relation to your bug description, then, I would say that this has always been the way that the system worked. You would check with something like :

If WinNT
  If WinXP
  EndIf
Else
  If Win9x
  EndIf
EndIf

That should properly evaluate in all cases.

jugg

2007-01-23 00:30

I have fixed this in CVS. My take on this is that if we document a variable, then it should always exist. So even on a Windows 2000 system, the variable $Win98$ should still exist, but should evaluate to "false".

The fixed entailed simply defaulting all of the platform variables to "false", and then setting the relevant ones to "true". This change should be backwards compatible.

The result is that now using these variables in runtime expansions (eg. !alert $Win98$) will not result in an "Variable Undefined" error box. The parser conditional of "IF Win98" will still evaluate correctly to "false". Modules also may now use these variables rather than the Windows API for determining what platform is being used.

core

crash

always

2006-04-29 10:55

2009-02-28 16:26

ilmcuts

none

closed

minor fix

< 1 day

0.24.7

fixed

GetToken might crash in unlikely cases

GetToken calls strlen(NULL) if pszToken is NULL and concatenation is used. This is a rare combination however.

lsapi.cpp.patch (1 KB) 2006-04-29 11:01

core

minor

always

2006-10-31 23:06

2009-02-28 16:26

jugg

none

closed

none

Windows

2000 Professional

SP4

0.24.7

fixed

"Dead" notification (systray) icons reappear on recycle

When an application is terminated without it removing its notification icons, any systray module will automatically remove the dead icon. However, on a recycle the core TrayService will send the "dead" icon back to the systray module causing it to reappear in the tray.

Load an application that adds a notificaiton icon to the systray, then from the taskmanager kill that application, so it does not cleanly shut down, therefore leaving its icon in the systray. Now, most systray modules will remove the icon when you mouse-over it (or during a set interval). Once the dead icon is removed from the tray, issue a recycle. It will reappear.

The problem appears to be the fact that the core TrayService itself never removes (or knows of) dead notification icons. A possible solution would be to scan for dead icons before enumerating and sending the icons to the systray. Perhaps this would be convienient inside of TrayService::SendSystemTray() (although it is currently a 'const' method)

jugg

2006-11-02 04:53

I went ahead and created a "removeDeadIcons" method in TrayService and called that method from the SendSystemTray function. SendSystemTray is no longer const because of this.

core

minor

always

2007-06-11 10:08

2009-02-28 16:25

jugg

none

closed

none

Windows

2000 Professional

SP4

0.24.7

fixed

Semicolon following ELSE or ENDIF statment breaks parser

Placing a semicolon immediately after an ELSE or ENDIF statement (with no whitespace) breaks the step.rc file parser.

Set the following in the step.rc:

a "true"

IF a
    test "true"
ELSE
    test "false"
ENDIF; comment

netloadmoduleonload !alert $test$

The "netloadmoduleonload" will not be executed in this instance, because the ENDIF statement did not evaluate, and the result is that the "netloadmoduleonload" line is part of the ELSE statement.

Set the following in the step.rc:

a "false"

IF a
    test "true"
ELSE; comment
    test "false"
ENDIF

netloadmoduleonload !alert $test$

The "netloadmoduleonload" line generates errors, because the ELSE statement did not evaluate, and the result is that the "test" variable is undefined.

Thanks to fractal.design for finding and pointing out this bug.
See http://lsdev.org/e107_plugins/forum/forum_viewtopic.php?1202 [^]

SettingsFileParser.cpp.patch (1 KB) 2007-06-26 13:33

jugg

2007-06-26 13:33

Working on it... I have a "simple" fix (see attached patch), but there is an unwanted side affect. So I'm looking for another solution.

jugg

2007-07-08 12:40

Fixed. Code is in CVS.

core

minor

always

2007-07-09 10:49

2009-02-28 16:25

jugg

ilmcuts

none

closed

none

0.24.7

fixed

The !about command can launch multiple concurrent About dialogs.

When executing the !bang command, it will launch as many instances of the About dialog as executed. It should only launch a single instance, and if the About dialog already is opened, then subsequent executions should simply give focus to the existing dialog.

Execute !bang more than once without closing previous instances of the About dialog.

ilmcuts

2007-07-31 17:20

Fixed both in branch and HEAD. Thanks to Acidfire for submitting a patch on the lsdev list.

core

minor

always

2007-10-06 09:17

2009-02-28 16:25

ilmcuts

jugg

none

closed

none

0.24.7

fixed

AppBar space from crashed apps is never released

If an application that has added an AppBar crashes or in any other way forgets to remove the AppBar, the screen space is never released. Maximized windows and new AppBars (added upon restart of the crashed app, for example) won't ever be able to use the space again.

[reported by the-golem in #litestep]

The only workaround currently is to !quit and restart litestep.exe. That is because desktop modules typically reset the workarea to the entire screen - thus the new litestep.exe process uses that as a starting point to add any new AppBars. If no desktop module is loaded, only a restart helps.

jugg

2007-11-06 13:11

I'm working on this.

jugg

2008-04-22 02:05

The lost appbar space is now recovered when any appbar message is received or when the working area is changed. This means that if the crashed appbar is restarted, then the space will be recovered, or if you re-adjust the workarea externally (ie. via a !recycle or whatever) the space will be recovered.

jugg

2008-04-24 10:54

Code has been merged into the 024x branch.

core

minor

always

2006-04-27 19:40

2009-02-28 16:24

jugg

none

closed

2006-03-30

none

Windows

2000 Professional

SP4

CVS-024x

fixed

Nested If/Endif with invalid expression syntax causes incorrect conditional block evaluation.

When nesting an If/EndIf conditional block statement, and the If expression syntax is invalid, this will cause the conditional parser to incorrectly parse the remainder of the step.rc, as the associated EndIf statement to the invalid If statement will close the parent If statement of the nested block. This may cause parsing problems throughout the remainder of the step.rc.

Example 1:

If 1
If pow(0)
; this is parsed
else
; this is not parsed - considered "else" to "If 1"
EndIf ; considered "EndIf" to "If 1"
Else ; ignored
; this is parsed
EndIf ; ignored

Example 2:

If pow(0)
; this is parsed
Else
; this is also parsed
Endif

While invalid syntax should be flagged to the user, it should not break the step.rc parsing.

Possible solutions are:

1. quit parsing the step.rc altogether, consider it an unrecoverable failure.
2. treat invalid syntax as if it the expression evaluated to false and continue parsing.
3. skip entire conditional block until the next EndIf

I've attached a patch for option 3.

SettingsFileParser.cpp.patch (1 KB) 2006-04-27 19:40

jugg

2006-05-24 00:35

I guess I'll go ahead and take this one on, and apply the patch to CVS.

jugg

2006-05-24 00:48

Patch committed to CVS (including a debug TRACE message)

core

trivial

have not tried

2006-05-04 14:54

2009-02-28 16:24

phil

Acidfire

none

closed

none

CVS-024x

fixed

Build date in !about is not updating (month)

Building LS today, the month in the compile date is reported as April in the !about box. No idea why yet.

compile_time.patch (2 KB) 2007-11-06 13:17
compile_time2.patch (3 KB) 2008-04-28 11:22

jugg

2006-05-06 17:07

The build date is created in .\lsapi\aboutbox.cpp (revision 1.18.2.6) line 260.

If the file is not recompiled, the date will not change. (ie. do a full recompile to have the build date updated).

This is something that needs fixed obviously so that it changes on any recompile. We probably need to make pre-build script which generates a "version.cpp" so that it is always compiled afresh.

jugg

2006-05-08 15:48

phil, please confirm whether or not this is resolved for you by doing a full rebuild of the project. I can not reproduce the problem as long as the aboutbox.cpp file has been recompiled.

phil

2006-11-11 14:16

Full rebuild appears to workaround it. Apologies for the delay in responding. Having it properly defined on any recompile would obviously be beneficial.

ilmcuts

2007-10-06 10:34

To fix this for good we can read the build date from litestep.exe's PE header.

jugg

2007-11-06 13:17

Adding patch from Acidfire

Acidfire

2008-02-12 03:21

Now fixed in head. This bug can be closed.

jugg

2008-04-28 11:24

Added patch against 024x branch which also checks for the build timestamp of lsapi.dll and hook.dll as well as litestep.exe and uses the most recent time of the three to display.

The new patch (compile_time2.patch) has been committed to 024x branch.

core

tweak

always

2008-04-22 12:34

2009-02-28 16:23

jugg

tobbe

none

closed

none

0.24.7

fixed

LSAutoHideModules doesn't show/hide modules when it should (CVS-024x)

Sometimes when using LSAutoHideModules ls gets confused and doesn't show the modules when leaving the full screen program that made the modules go away in the first place.

Open a full-screen program, like a video player. Alt-Tab to some other program. The modules should now be made visible, but they aren't

This issue was cloned for the 024x branch to remain Win95 compatible. The following code should be essentially what we want:

bool CLiteStep::_IsFullScreenOnPrimaryMonitor(HWND hWnd)
{
    RECT rScreen, rWnd;

    rScreen.left = 0;
    rScreen.top = 0;
    rScreen.right = GetSystemMetrics(SM_CXSCREEN);
    rScreen.bottom = GetSystemMetrics(SM_CYSCREEN);

    GetWindowRect(hWnd, &rWnd);

    return FALSE != EqualRect(&rScreen, &rWnd);
}

litestep24x.patch (6 KB) 2008-04-24 14:03
autohide.patch (7 KB) 2008-04-25 11:04
fullscreen.patch (7 KB) 2008-08-16 14:16

tobbe

2008-04-24 14:04

The patch uses GetWindowPlacement instead of GetWindowRect

jugg

2008-04-25 11:05

Added autohide.patch (04-25-08 11:04) which fixes the issue with WINDOWPLACEMENT containing the window rect in Workspace coordinates rather than screen cordinates.

It also prevents GetforegroudWindow() from being called anytime a different application gains focus. Rather now it only calls it when a fullscreen window exists.

tobbe

2008-05-10 00:43

It's fixed now, but improvements can still be done. In particular it would be nice to get rid of the Sleep(1);

tobbe

2008-06-03 03:27

It still doesn't work for VLC or Foxit PDF Reader. Since those are popular programs I think it's important we make it work for them.

jugg

2008-06-08 14:41

It works fine with VLC for me.

pirlouy

2008-06-08 16:28

I also have problems with LSAutoHideModules. With softwares like Zoom Player or FastStone MaxView (which are both good examples), modules (xTaskbar, xTray, xLabel) stay before the image/video whereas these app' are in Full screen and thus should be before modules.

Discussion started here: http://www.ls-universe.info/plugins/forum/forum_viewtopic.php?10442 [^]

I use Windows XP, Ls 0.24.8 RC1.

jugg

2008-08-16 14:17

Added a new patch (fullscreen.patch 08-16-08 14:16) that fixes all test cases provide by Tobbes Fullscreen test app.

jugg

2008-08-18 01:38

I've committed to CVS an updated version of my previous patch. Tobbe, please test and mark this issue resolved if it is working for you.

tobbe

2008-08-19 13:39

jugg's latest patch seems to fix all reported problems

tobbe

2008-08-19 13:45

jugg's latest patch seems to fix all reported problems

core

tweak

always

2008-05-12 18:48

2009-02-28 16:23

jugg

Acidfire

none

closed

none

0.24.7

fixed

$CompileDate$ can be incorrect

The $evar$ "CompileDate" may not be updated when doing a minimal rebuild and it does not match the compiled on date displayed in the !about box.

It seems the correct solution is to make the !about box use the $compiledate$ evar, and populate that evar with the date using the method the about box was using to determine the compile date.

Acidfire

2008-05-14 11:00

Fixed in both head and branch.

core

major

always

2008-06-16 12:54

2009-02-28 16:22

paokaoru

jugg

none

closed

none

CVS-024x

fixed

At 0.24.8-RC1, tray icons' balloontips can't be viewed

If the string which will be printed as the balloon tooltip contains non-ascii character, the balloon will never pop up.
with 0.24.7, this problem does not happen. only on 0.24.8-RC.
(with xtray2.x, xtray1.x, the same problem happens.)

jugg

2008-06-17 07:33

What program puts an icon in the tray that uses non-ascii characters? Preferably one with a download link... Thanks.

paokaoru

2008-06-20 09:00

Well, I'm in Japan and I have many, but I don't know whether it does print non-asciis in non-Japanese environments...

http://my.vector.co.jp/servlet/System.FileDownload/download/http/0/72726/pack/win95/amuse/saver/tool/ss220.lzh?ds [^]

This would be a good example, because it contains ASCII strings "for WinNT" after non-ASCII ones.

jugg

2008-08-18 01:49

I've tested the app you have linked. I can see the tooltip just fine. Is this program also supposed to show a Balloon Info Tip?

jugg

2009-01-08 11:56

I am unable to reproduce this problem with xTray 1.1.1 or xTray 2.2 or any other systray module.

The tooltip shows up just fine (with a bunch of unknown characters followed by 'for WinNT').

Please respond with detailed Steps To Reproduce. No one else has experienced or confirmed this issue, so unless we hear back we will be closing this issue as invalid.

ilmcuts

2009-01-10 10:32

I too could not reproduce this issue. A balloon with Ʒ (U+01b7) did show up - albeit with question marks instead of the unicode characters.

EDIT: Apparently our bugtracker doesn't handle this character either.

jugg

2009-01-20 23:11

tnl in #litestep has confirmed that this is an issue with ToolTips, not Balloon/InfoTips. When using 0.24.7 with japanese IME installed the tooltip shows up just fine:

http://i300.photobucket.com/albums/nn20/HOSB5NM7/ss.png [^]

However, when using 0.24.8 RC1, the same tooltip does not show up. He has tested with xtray-2.0.2 and systray-1.10.

jugg

2009-01-21 11:24

After further work with tnl on #litestep, we have indeed confirmed this issue as existing in 024.8 but not in 024.7. The issue is incorrect usage of WideCharToMultiByte, as it expects the input string length, not the input buffer size.

jugg

2009-01-21 11:28

The fix has been committed to CVS 024x.

core

major

N/A

2008-08-15 13:38

2009-02-28 16:22

jugg

none

closed

none

CVS-024x

fixed

Backport major bug fixes from HEAD to the 024x branch

This issue will track all bug fixes being made in HEAD that need to be backported to 0.24.8, rather than making an individual issue for each fix.

TODO:
* NA

COMPLETED:
* Fix potential crash bug: RemoveBangCommand(NULL) should return FALSE
* Fix subkeys of RunOnce not being deleted
* Fix issues with StartupRunner not waiting for apps to finish loading and not checking the error code correctly
* Fix BOOL/bool type mismatch issues
* Fix bug in fullscreen app detection: Replace bogus ASSERT with VERIFY

jugg

2008-08-18 01:43

I will re-open this issue if necessary. For now marking as resolved.

core

minor

always

2008-07-01 11:54

2009-02-28 16:21

klingens

jugg

none

closed

none

0.24.7

fixed

!about box system information does not display above 2gig of memory

wols reported in #litestep:

!about has bad system information. minor bug. I have 4 GB (3.5GB usable) and LS tells me I have 2GB and the pagefile sizes are probably inflated instead.

Windows XP SP2

Have 4GB of ram installed, and show the !about box system information page.

wols_: yes. pyhs mem total 2GB, Physmem available 2GB, Swap Space total 4GB, Swap space available 3GB
wols_: actually I have 4GB, 3,5GB usable and a pagefilesys of 1GB
wols_: I think you should use less signed integer jugg :)
wols_: maybe add that about the signed integer. 99% it's the culprit
jugg: ok :)

ilmcuts

2008-07-23 16:31

Curiously, it does show 4 GB "Physical Memory Total" on my Vista system. At the same time, here too it should really display 3.5GB or something slightly larger but below 4 GB. That could be due to rounding, of course.

jugg

2008-08-19 17:12

We use GlobalMemoryStatus() function which is limited to reporting 2GB unless the application calling it is linked with /LARGEADDRESSAWARE switch.

It is possible to update an .exe with that flag using the "editbin" utility.

If someone wants to verify this, please use the "editbin" utility from VS, against your litestep.exe. Like so:

editbin.exe /LARGEADDRESSAWARE C:\PathTo\litestep.exe

(be sure to not have litestep.exe being used at the time)

You can always revert the change by doing:

editbin.exe /LARGEADDRESSAWARE:NO C:\PathTo\litestep.exe

alurcard2

2009-01-02 18:21

<alur> won't you have to abandon it anyway when you want to be able to show >= 4gb of ram? and I'm not really certain on how that stuff works, but couldn't you just call GlobalMemoryStatus when you have a 9x system and GlobalMemoryStatusEx otherwise?
<jugg> alur: probably, feel free to suggest it in a comment on bug 0000058.

ilmcuts

2009-01-03 03:08

Yes, /LARGEADDRESSAWARE only fixes the >2GB && <=4GB case:
http://msdn.microsoft.com/en-us/library/aa366586(VS.85).aspx [^]

jugg

2009-01-20 18:20

Using alurcard2's suggestion, we now use GlobalMemoryStatusEx function on systems that support it (Win2k+) which nicely correspond to systems that support >2GB of memory. Thus fixing this issue. The change is in CVS 024x.

core

minor

always

2009-01-13 22:09

2009-02-28 16:21

jugg

none

closed

none

CVS-024x

fixed

The v0-24-x branch mingw makefile does not successfully compile the source code

Trying to compile the CVS 024x branch with MinGW (using the nuwen.net 4.0 distro) the build fails immediately on aboutbox.cpp - can't resolve isspace() function. However, fixing that and several other minor issues still leaves many more unresolved.

Download mingw-4.0.zip from nuwen.net, extract the files, open a command prompt and set the path to include the extracted mingw/bin folder. Change to the folder containing the CVS 024x branch of code, and type: make

jugg

2009-01-27 17:37

The fix has been committed to CVS-024x. The code now compiles (albeit with quite a few warnings). But we'll leave fixing those as an exercise for anyone interested in building this branch using mingw.

If you are interested in hacking on the source using mingw, please consider compiling against CVS-HEAD, as it has up-to-date support for mingw.

core

feature

always

2008-12-29 11:19

2009-02-28 16:21

tobbe

jugg

none

closed

none

Windows

XP Professional

SP2

0.24.7

fixed

LiteStep only reports full gigabytes of memory

On the System Information page of the !about dialog the Physical Memory is reported rounded to the closest GB.

It should be able to show 1.5GB or 1.75GB etc

maduin

2008-12-30 11:00

One possible solution would be to replace the FormatBytes functions with a call to StrFormatByteSize (from shlwapi). This way the byte size would be formatted the same way as the rest of the shell.

Of course another solution would be to just remove the system info from the about box--it doesn't really need to be there.

jugg

2009-01-20 12:33

I updated the aboutbox.cpp FormatBytes function to conditionally handle GB formatting to show .2 precision on the decimal place. Code committed to CVS 024x branch.

core

minor

always

2008-01-10 06:41

2009-02-28 16:21

ilmcuts

jugg

none

closed

none

0.24.7

fixed

Re-entrancy issues in TrayService

There are several re-entrancy issues in the AppBar code in particular. Whenever we loop over the appbar vector and call SendMessage, there is a chance for re-entrancy. We could for example receive ABM_NEW or ABM_REMOVE. That would modify the internal appbar vector, leading to a crash when execution flow returns to the original loop.

See http://blogs.msdn.com/oldnewthing/archive/2004/06/08/150929.aspx [^]

appbarcreator.zip (8 KB) 2008-04-25 11:28

ilmcuts

2008-01-10 06:44

I've been able to provoke such potential crashes several times. The intermediate vector modifications trigger an assertion inside the vector implementation next time we try to advance in the loop.

jugg

2008-04-14 10:20

Yah, definitely an issue. The code probably should be re-thought anyhow. The implementation was created in a "reverse engineering" mode. So, it is probably incorrect, and definitely wasn't thought through in terms of "is this the best way". However, the user-visible behavior (minus crashes?) of the current implementation is similar to what Explorer provides.

Attached is my "test tool" for appbars.

jugg

2008-04-22 02:10

Taking ownership of this bug... since the rest are mainly Vista issues which I can't work on and I'm familiar with this code and plan on rewriting a good portion of it anyway.

jugg

2008-04-25 11:26

Pushing this issue back to 0.25.0 release as the entire AppBar service needs to be rewritten, and the effort to fix this re-entracy issue really is too much part of the larger effort to make this inititial fix worth while right now.

jugg

2009-02-23 22:10

Fix committed to both HEAD and 0-24-x branch.

core

minor

always

2008-12-31 04:12

2009-02-28 16:20

ilmcuts

jugg

none

closed

none

0.24.7

fixed

ABM_GETTASKBARPOS needs to set uEdge on return

Some applications (e.g. the Vista volume slider) use the uEdge member of APPBARDATA to calculate their position.

ABM_GETTASKBARPOS is not documented as setting uEdge, but apparently Explorer does so.

jugg

2009-02-23 22:10

Fix committed to both HEAD and 0-24-x branch.

core

minor

always

2009-01-11 06:29

2009-02-28 06:12

ilmcuts

none

closed

none

unable to reproduce

Handle leak in AboutBox

The AboutBox code seems to have a handle leak. If you run !about and close the box a few times, the process handle count goes up by one for each box.

jugg

2009-01-13 22:19

Please specify what LS version: 0.24.7, CVS-024x, or CVS-HEAD. What OS?

I am unable to confirm this running CVS-024x (2009-01-13) on Windows 2000 SP4.

ilmcuts

2009-02-28 06:12

I cannot reproduce this any more either. Bug closed and marked as "unable to reproduce".

core

trivial

always

2008-05-06 08:59

2009-02-28 05:44

Acidfire

none

feedback

none

open

!runstartups to use when LSNOSTARTUP is set

Requisted by WoXoW: "It would be lovely to have a bang command such as !runstartups when LSNOSTARTUP is set to true and one wants to start the programs that are suppose to be autostarted."

ilmcuts

2008-07-21 05:00

While this can certainly be implemented, I do wonder about the motivation behind this. Is there maybe some problem in our startup timing that he wants to work around?

Delf

2008-08-04 13:47

Nothing wrong with the startup timing that i have noticed. Is this going to be implemented in the next release?

Delf

2009-01-16 22:46

The motivation would be speed and freedom. Sometimes you logon to do something fast without being slowed down by all the autostartups. When finished doing your fast business you will be able to run your autostartups on fly using bang command. Sometimes themers use animations for their themes to load such as fading/sliding in/out elements and want that to be made in peace without lagginess caused by the autostartups. There are many situations this function would prove useful in.

BTW im WoXoW.

ilmcuts

2009-01-17 11:04

But if this is needed to (among other things, as you noted) work around animation issues then we should rather fix the issues than provide a workaround.

Delf

2009-01-17 12:08

Animation issues are not the motivation. Flexibility and the freedom of choice is. Sometimes you logon do your business without needing your autostartups then log off or shutdown. In some cases you dont want to log of or shutdown as you may have changed your mind and want to have your autostartups to start. Of course one can log off then log back on without holding SHIFT key down (assuming LS is set to "default" autostartups setting).

core

feature

always

2006-05-04 15:05

2009-02-28 05:43

phil

none

feedback

none

CVS-trunk

reopened

includefolder patch for CVS

Apply attached patch to add includefolder support to lsapi.

Note that you will need to add the build option for this to be compiled in.

An additional patch will follow to set includefolder as an EVar to allow themes to check for the provision of this feature and failsafe if not found.

All credit to ilmcuts for developing this for LDE(X) over IRC :)

SettingsFileParser.cpp.patch (2 KB) 2006-05-04 15:05

phil

2006-05-04 15:09

This feature has been implemented in LDE(X) since version 6.0, released 3 years to the day today :) No breakage or issues have ever been reported with this feature, for what it is worth.

jugg

2006-05-06 20:20

Thanks for the patch, we'll take a look at it.

jugg

2007-05-07 17:55

Phil, I have this patch merged with the 0.24.x branch, and but it will only be compiled into the code with a specific #define enabled, which won't be enabled on normal lsdev releases. I know this isn't perfect, but at least this way you don't have to maintain a seperate code base for this patch.

Anyway, what I need to know is what the variable name is that needs to be set? Just "includefolder"? Can it be something different? Perhaps "LSHasIncludeFolder"="TRUE"?

jugg

2007-05-23 16:15

I found in the LDE documentation the original patch discussed here Page 80-81:

http://ldex.terica.net/software/releases/X6.4/core.pdf [^]

The variable that needs to be set is simply: includefolder=1

phil

2007-06-12 06:44

Yeah. I documented the patches in that PDF. Apologies for the oversight in the original submission.

jugg

2007-06-12 10:33

I have the code merged locally. Just need to commit to CVS after testing.

jugg

2007-06-24 15:39

Modified version of the patch applied to CVS 024x branch. It is not enabled by default. Uncomment relevant line in buildoptions.h to enable conditional compilation for non LSDev builds.

phil

2009-02-13 12:16

Could this be enabled by default?

jugg

2009-02-23 21:09

Removing from 024.8 release as it will not be enabled by default for said release.

ilmcuts

2009-02-28 05:31

We discussed overloading "include" to work on directories.

A (major?) problem might be that there's no guaranteed include order.

core

major

always

2008-05-16 12:34

2009-02-23 22:16

jugg

none

closed

none

CVS-trunk

won't fix

GetRCLine() incorrectly returns parsed value

When calling GetRCLine(), the returned value has any contained e-vars already expanded. This should not be. GetRCLine() should return a "raw" value.

char tmp[128];
LSSetVariable("MyVar", "Hello");
LSSetVariable("MyLine" "$MyVar$");
GetRCLine("MyLine", tmp, 128, "");

Inspect "tmp". It will contain "Hello" rather than "$MyVar$".

For compatibility the 0.24.x releases maintained this incorrect behavior. Because this will affect existing modules and configurations, changing this needs to be considered carefully.

Acidfire

2008-05-16 14:19

Maybe make a separate GetRCLineRaw() instead? This would keep compatibility with modules and still allow future use of GetRCLine() for people who want that behaviour.

jugg

2008-05-17 16:07

The GetRCLineRaw() (under a different name) has been considered:

http://www.lsdev.org/doku.php?id=lsdev:discussion:core [^]

The annoying part about this is that until 0.24.6 this function worked correctly, but I believe it was IndieStep that changed it, and then kept for 0.24.7 for "compatibility" reasons. So this bug report is filed from the perspective that 0.24.7/8 releases diverge from the original API implementation.

If nothing else, LSGetVariable() should be returning an unparsed value (ie. it should return exactly what it was set to). So, I'm marking this issue related to bug 0000048. It really comes down to us laying out the existing API functionality, and defining exactly what we want, and updating it.

jugg

2009-02-23 22:16

All GetRCxxx() functions will expand $evars$. This will not change. As previously noted LSGetVariable() certainly should not be expanding $evars$ however. But this specific report is now closed, and marked as invalid.

core

tweak

always

2008-04-14 11:39

2009-02-23 21:45

tobbe

jugg

none

resolved

none

Windows

XP Professional

SP2

CVS-trunk

fixed

LSAutoHideModules doesn't show/hide modules when it should (CVS-trunk)

Sometimes when using LSAutoHideModules ls gets confused and doesn't show the modules when leaving the full screen program that made the modules go away in the first place.

Open a full-screen program, like a video player. Alt-Tab to some other program. The modules should now be made visible, but they aren't

litestep.patch (6 KB) 2008-04-17 14:36

jugg

2008-04-19 01:34

The patch looks good except for the use of SCREEN_HEIGHT and SCREEN_WIDTH macros. On a multimonitor system, these will give you the Virtual Screen size, which is decidely not useful in the way those values are used.

jugg

2008-04-19 15:16

So, thinking about this, it seems a simpler implementation of _IsFullScreenOnPrimaryMonitor() would be something like (untested):

bool CLiteStep::_IsFullScreenOnPrimaryMonitor(HWND hWnd)
{
    RECT rScreen, rWnd;

    rScreen.left = 0;
    rScreen.top = 0;
    rScreen.right = GetSystemMetrics(SM_CXSCREEN);
    rScreen.bottom = GetSystemMetrics(SM_CYSCREEN);

    GetWindowRect(hWnd, &rWnd);

    return FALSE != EqualRect(&rSreen, &rWnd);
}

jugg

2008-04-20 17:55

Another reason to change the code is that MonitorFromWindow() et al are not available on Win95. Again, until we make a decision to drop support for Win95, or even Win9x, we need to ensure to remain compatible. So that is a discussion to be had if necessary.

tobbe

2008-08-19 13:52

Need to port the code from 0.24.x. It needs to be updated to support multiple monitors.

jugg

2009-01-20 15:07

my idea for multi-mon support is to abuse the BangCommand hParent handle by passing it a HMONITOR handle for the monitor we detected a FS app on. Then in !HideModules, use GetMonitorFromWindow() and if its equal to the overloaded hParent handle, hide the module, otherwise skip over that module. !Showmodules won't change, as it should always show all modules that were previously hidden.

jugg

2009-01-24 22:50

Now that Tobbe has merged the 024.x changes and I've updated HEAD with further fixes to FS detection based on our research, is there anything else left to do? It seems functional to me.

Tobbe, if you are satisfied that the current FS code resolves this particular bug report, please mark it resolved.

jugg

2009-02-23 21:45

This was resolved in CVS on "Thu Jan 22 03:19:57 2009 UTC".

core

minor

always

2006-04-29 05:10

2009-02-23 21:21

ilmcuts

jugg

none

resolved

none

CVS-trunk

fixed

The SDK's include/lsapi.h and core lsapi declarations of LC* functions are different.

The LC* functions are documented to use LPVOID instead of FILE* and the SDK include/lsapi.h header file uses LPVOID. However, the core code still uses FILE*.

Since sizeof(FILE*) == sizeof(LPVOID) this can be changed in the headers without breaking binary compatibility. However, it does break code compatibility - whenever an old module is compiled all instances of FILE* will need to be changed to LPVOID. This is just a single variable usually. C may actually tolerate assigning an LPVOID to a FILE* (haven't checked), but C++ shouldn't.

ilmcuts

2006-05-04 05:21

At this point I think we should change the docs. The advantages gained by changing our stuff to LPVOID don't make up for the trouble this would cause (modules won't compile any more). Using FILE* has worked for years. Using LPVOID would actually make more sense, but if we are to introduce a new settings API in the trunk we could just leave this as is and save us the trouble.

jugg

2006-05-06 20:18

I agree that LPVOID should be used. But because FILE* has always been used in the 024.x series, perhaps we should leave it. Does anyone else have any input on this?

jugg

2007-05-07 18:19

The code simply needs to be changed. Its bogus passing a FILE* around when it isn't actually one. There is no reason to require "compilation" backwards compatibility. Binary compatibility is one thing and understandable, but I see no reason to ensure that an old module source can be compiled without being changed.

jugg

2009-02-23 21:21

This was fixed in the commit with the log message: "Massive update to bring the entire code base into a generally consistent format."

core

trivial

N/A

2009-01-23 11:15

2009-02-23 21:19

jugg

none

resolved

none

CVS-trunk

fixed

Stub out win95 specific multi-monitor functions.

With the code in CVS HEAD no longer supporting Windows 95, I see no reason to keep the following Win95 specific functions around:

LSGetSystemMetrics
LSMonitorFromWindow
LSMonitorFromRect
LSMonitorFromPoint
LSGetMonitorInfo
LSEnumDisplayMonitors
LSEnumDisplayDevices

However, because modules currently use these functions, I think the appropriate solution is to stub them out as direct wrappers to the Win32 equivalent and place them into lsapi/stubs.cpp.

Also, the core code should no longer use them, and instead directly call the Win32 equivalent.

jugg

2009-02-23 21:19

The change is in CVS, but I forgot to add this issue id to the commit log. :(

The change was committed on "Thu Feb 12 23:22:30 2009 UTC"

core

feature

always

2009-01-27 09:43

2009-02-16 22:30

jimrandomh

Acidfire

none

feedback

none

open

Path separation functions in evar expansions

It would be useful to have functions for splitting apart paths in evars. Given an absolute path,
  DrivePart(path) returns the drive letter
  DirPart(path) returns the path
  FilePart(path) returns the filename (including extension)
  ExtPart(path) returns the extension

jugg

2009-01-27 10:10

If a relative path is given, I suppose we could base it off of $LiteStepDir$?

Anyway, this looks good, we'll need to decide on the formal function names. The proposed ones work, but i'd like to start grouping functions by name that belong together... pathDrive() pathDir() pathFile() pathExt() ? Although the "part" postfix is more descriptive of what the function does... Ideas?

jugg

2009-01-29 13:13

Would it be more appropriate/fitting to instead provide functions like rtrim, ltrim, substr etc to let people parse their own strings/paths?

Acidfire

2009-02-13 04:28

How about before_first, before_last, after_first and after_last?

jimrandomh

2009-02-16 22:30

I don't think that before/after_first/last functions are a good idea for path manipulation, because using them to implement path manipulations is likely to be brittle. For example, before_first("\", "C:\Program Files") is "C:", but before_first("\", "C:/Program Files") is "". Relative paths are likely to have similar problems. Also, they would just be special cases of replace(regex,string,string), which is much more generally useful.

core

trivial

always

2009-01-12 06:29

2009-02-07 21:21

ilmcuts

none

closed

none

not fixable

Minimized Task Manager does not disappear from taskbar

Under Explorer, Windows Task Manager only shows a taskbar button when it's shown. When it's minimized, only its tray icon is visible - the taskbar button disappears. Under LS, the taskbar button stays no matter what.

This could be a bug in the taskbar module, in my case taskbar3 0.306 alpha 3 (sic).

ilmcuts

2009-01-16 16:27

According to alur, this happens with xtaskbar as well

jugg

2009-01-16 16:51

I have confirmed on Windows 2000 that when the Options->HideWhenMinimized is checked that it indeed hides under explorer but not under LiteStep using tasks.dll or screewvwm.dll

What OS are you all testing on?

ilmcuts

2009-01-16 17:16

I'm on Vista. Setting LSSetAsShell fixes this. Dependency Walker reveals that Task Manager imports GetShellWindow.

alurcard2

2009-01-17 11:31

I'm on XP, and LSSetAsShell fixes it here as well.

jugg

2009-02-07 21:21

There is nothing to do here. The Task Manager requires a registered shell application in order to minimize to the systray. Enable LSSetAsShell if you require this functionality.

core

minor

always

2009-02-03 13:44

2009-02-07 21:19

Delf

none

closed

none

CVS-trunk

not fixable

Unable to map hotkey when LSSetAsShell TRUE

Using anykey.dll (1.0) it is not possible to map keys CTRL ESCAPE
when LSSetAsShell TRUE is set.

jugg

2009-02-07 21:19

Windows automatically registers a hotkey for the WinKey, and if there is a shell application, it also register a hotkey for CTRL+ESCAPE.

Both of those hotkeys are used to produce the Shell Hook message: LM_TASKMAN

A module can register for that message, and execute an abitrary command, ie !popup

The only way to prevent Windows from registering CTRL+ESCAPE is to not set LSSetAsShell. It is not possible to prevent Windows from registering the WinKey.

core

feature

always

2009-01-09 20:05

2009-01-27 09:54

crazy2be

none

closed

none

0.24.7

won't fix

Add $litestepdrive$ functionality to the core

Not a biggie, just looking for potential $litestepdrive$ functionality to the core. (i believe this was in the bugtracker before the bad host)

this could be useful to people running litestep off of a USB stick, although my ShellSwitcher program does this already (writes LSD "E:\" to an rc file)

Just if someone can get around to it. it's low priority, but it shouldn't be hard.

Acidfire

2009-01-27 09:53

The requested functionality will be covered by the solution to bug 0000084 (see relationship).

core

major

always

2009-01-25 13:39

2009-01-25 13:55

jimrandomh

none

feedback

none

open

SendMessageTimeout(WM_GETICON) causes Litestep to lock up whenever an app stops handling messages

Many modules use SendMessageTimeout to send WM_GETICON messages to applications to retrieve their icons. If an application is crashed in such a way that it can't handle the message, then this will block for the full timeout, making Litestep unresponsive in the mean time. During that timeout, various timers will go off triggering a redraw which requests icons again, with the result being that Litestep spends all of its time waiting on WM_GETICON messages, and only handles its other events in between.

Once events stop being handled, the system descends into a death spiral of Litestep waiting for everything and everything waiting for Litestep. Apps block waiting for Litestep to handle its events, and Litestep blocks waiting for those apps to handle their WM_GETICON messages. Windows has a mechanism that's supposed to protect against waiting forever for messages, SMTO_ABORTIFHUNG, but everything still handles its messages, just very slowly, so Windows doesn't recognize things as hung.

Affected modules include tasks2, rabidvwm, and xtaskbar. ScreenVWM is not affected, because it only polls icons once per window (with the side effect of not noticing when windows change their icon).

jimrandomh

2009-01-25 13:55

This is a complex issue with a lot of moving parts involved, and I'm not at all sure of the details. It depends on the details of Windows' hung-app detection, which may depend on the operating system version and the number of cores. It also depends on the relative priorities of the various processes involved. This issue is not new; it has probably been around for as long as there have been modules using app icons. However, because reproducing it depends on so many fiddly details and requires another app to crash, it hasn't been properly recognized as LiteStep's fault.

The end result of this issue is that one crashed app causes the entire system, not just LiteStep, to crash with it. This is too severe to ignore.

The fix is to forbid all modules from using SendMessage and SendMessageTimeout to send messages to non-LiteStep windows from the main thread. This means we need another thread to use for retrieving icons, and I think that ought to be part of the core.

core

feature

N/A

2008-04-25 15:52

2009-01-25 13:29

jugg

tobbe

none

resolved

none

fixed

Use LodePNG for png image support

Instead of depending on a large external library like libpng like we currently do (and subsequently the zlib library), we could switch over to LodePNG's picopng.cpp c++ class. Since we currently only support loading of .png images this would be a useful way to go.

We could target 0.25.0 for picopng.

LodePNG can be found at: http://members.gamedev.net/lode/projects/LodePNG/ [^]

This would greatly simplify the build dependencies of LiteStep.

In the future if we want to support different image effects, we could use the larger lodepng.cpp c++ class as well. This is still self contained, and smaller than depending on the current libpng library.

I see this as a first step in creating a better graphics library for modules internal to the core.

ilmcuts

2009-01-10 09:41

picoPNG is now enabled by default on HEAD.

ilmcuts

2009-01-11 06:31

The change was reverted. According to alur, the PNGs appear inverted.

tobbe

2009-01-25 10:05

A closer look revealed that the png images were in fact mirrored (flipped horizontally) and not inverted. The images are now drawn correctly.

alurcard2

2009-01-25 11:04

There are still some transparency issues with picoPNG.

My theme will end up looking like http://dl.getdropbox.com/u/51925/2009-01-25_100731.png [^] instead of like http://dl.getdropbox.com/u/51925/2009-01-25_100927.png [^]

tobbe

2009-01-25 13:29

Support has been added for transparency.

core

minor

always

2009-01-22 21:12

2009-01-24 22:50

jimrandomh

tobbe

none

feedback

none

open

Transparent fullscreen apps hide modules

Under Windows Explorer, fullscreen apps cause the tray to cease to be always-on-top, but not to hide itself. This means that if a program creates a full-screen window but hides it or makes it transparent, you can still see the tray. Under Litestep, full-screen apps are either not handled, or are handled with LSHideModules hiding them. This means that when VirtualBox enters "seamless mode", modules disappear, even though seamless mode is only visible inside the work area. (It covers the whole screen, but the part which is over the tray is transparent.)

jugg

2009-01-23 08:53

The behavior is correct - that we enter our FullScreen state when VirtualBox is in its "seemless" mode.

However, we might want to consider what our FS handler does - ie. instead of hiding modules, instead make them not always-on-top and send them to the back of the z-order. Some module's try to catch z-order changes however, and will put themselves right back on top. These modules are "broken", so, we could implement FS handler change and tell people to complain to the broken module's author when it doesn't go behind the FS window.

Tobbe, can you add a test to your FS test app which creates a valid FS window but sets its window region to not cover outside the work area. Feel free to un-assign yourself from this if you're not interested. :)

jugg

2009-01-23 15:23

If we switch to toggling ontop status of modules, we should use the open class style bits, rather than changing the magicdword, for tagging whether a module has been modified by the fullscreen handler.

core

feature

always

2009-01-23 11:39

2009-01-23 12:36

tobbe

none

feedback

none

open

Preprocessor additions

A useful addition to the LiteStep .rc preprocessor would be to be able to specify groups of settings.

The name of a group is specified by prefixing it with an at symbol (@). The at symbol should be the first non-whitespace character on that line.

The start of the group is marked by an opening curly brace. The group name and the brace should be separated with one or several whitespace characters (' ', \t, \r, or \n).

The end of a group is marked with a single closing curly brace on a line of its own.

Groups can be nested.

The name of the current group can be referenced by a single at character for use as an argument to any of the settings in the group. Use two at characters to reference the parent's group name. The group name always includes the name of all parents, grandparents etc if they exists.

This should not replace the current syntax, but rather be provided as an option that can be used alongside the traditional syntax.

Example:

@BottomBar {
    Type flow
    X 0
    Y -20
    Width $ResolutionY$
    Height 20

    @TextArea {
        Text @
        Tooltip @@
    }

    @VDM {
        Type flow
        Desks 4
        ShowIcons false
    }
}

The example above is equivalent to the following:

BottomBarType flow
BottomBarX 0
BottomBarY -20
BottomBarWidth $ResolutionY$
BottomBarHeight 20

BottomBarTextAreaText BottomBarTextArea
BottomBarTextAreaTooltip BottomBar

BottomBarVDMType flow
BottomBarVDMDesks 4
BottomBarVDMShowIcons false

jugg

2009-01-23 11:48

To clarify one point, I believe the first syntax example is translated by the preprocessor into, and stored as, the second (traditional) syntax example for access by the settings API.

jimrandomh

2009-01-23 11:58

This has been discussed a bit in #lsdev, but I'd just like to repeat it here for anyone who wasn't there. The main reason for this is because of screenvwm, which involves lots of elements (identified by prefix) referring to eachother in the config, which gets rather confusing with the normal syntax and means lots of opportunities for unnoticed typos in variable names. This applies to other modules too, just to a lesser extent.

Note that, while '@@' in this example means parent-of-parent, '@Var1 @Var2' is indeed valid, and gives the (single-)parent prefix two times.

jimrandomh

2009-01-23 12:04

Also, for full generality, this ought to include starred config entries. For example,

@Prefix
{
*Foo Arg
*Bar @Arg
}
expands to
*PrefixFoo Arg
*PrefixBar PrefixArg

(Also note the curly brace on the next line, which I think ought to be supported.)

jugg

2009-01-23 12:30

Question, is the delimiter now a "super char" like $ is? ie, can it no longer be used in strings (like $ can not be used in strings)?

input:
@TextArea {
Text @
}
output:
TextAreaText TextArea

input:
@TextArea {
Text "@"
}
output:
TextAreaText "@"
or
TextAreaText "TextArea"

I think it has to be a "super char"... and replace @ within quotations as well.

jugg

2009-01-23 12:36

re: 0000192

Two ways to look at it... I'm not saying one is more right.

input:
@*Prefix
{
Foo Arg
}
output:
*PrefixFoo Arg

input:
@Prefix
{
*Foo Arg
}
output:
Prefix*Foo Arg

perhaps they should both produce the same output.

Also your comment about the curly bracket on the next line... the original spec above already states that is valid.

core

minor

always

2008-12-29 11:48

2009-01-16 16:23

ilmcuts

none

feedback

none

open

Compatibility - Mystery Bugs

This is a parent issue for compatibility issues that have no obvious fix and/or require LiteStep to support undocumented behavior.

jugg

2009-01-03 23:12

Please be sure to specify your OS version when reporting these types of bugs!

core

minor

always

2008-01-13 12:41

2009-01-16 16:20

ilmcuts

none

confirmed

none

open

Implement Vista changes to NOTIFYICONDATA

The NOTIFYICONDATA struct has a few new flags and a new member, hBalloonIcon. We're probably leaking the latter currently.

core

feature

N/A

2006-06-05 13:00

2009-01-16 16:20

phil

none

feedback

none

CVS-024x

open

Merge sidestep features for advanced image handling

http://eric.redtetrahedron.org/readme.htm [^]

Source is available, but patch generation is awkward due to invasive nature of changes across LS code.

jugg

2007-05-07 18:18

We will look into it.

core

feature

N/A

2007-06-28 10:00

2009-01-16 16:20

phil

none

feedback

none

0.24.7

open

ExecuteAndWait support

Maduin implemented this some time ago in our LDE(X) LS branch. I've only just located the change :

http://omni.terica.net/omniscience/changeset/470 [^]

The intention behind this change was to sidestep the endemic timing issues that LiteStep has when running external processes. We see this a lot with scripts called from LS (e.g. WSH support structures, or AutoIT dialog integration) where we have basically to put LS into a tight mzScript loop and watch for a return variable being created. If we don't do this, many bad things happen as values are not available, or support structures are invalid because we get a race condition between LS and the external process(es)

The loop-lock approach works, usually, but has the limitation that mzScript is required. Reliability in this situation is also not particularly enviable; if the external process quits with an error, the tight lock is not ended and the user is required to terminate LS with prejudice.

Maduin's approach was taken some time ago and I confess to having asked for it and then not made use of it. Nonetheless, I think it would be a worthy thing to have in mainline, if only to allow others to avoid the heavy workarounds that LDE(X) implemented.

Since we have not used this approach in LDE(X), reliability and correctness is not known.

jugg

2007-07-07 13:46

Thanks. Since it is just a !bang command any module could implement this.

However, if we implement it in the core, we should also expose it via API, so modules can directly make use of it as well. (example: !execute is a wrapper around LSExecute)

core

feature

N/A

2008-06-13 11:40

2009-01-16 16:18

maduin

none

feedback

none

open

Lengths, Units, and Resolution Independence

Problem:

LS modules only support lengths given in pixels, which makes themes very sensitive to screen resolution.

Proposed Solution:

Add a new "length" data type to step.rc with support for multiple units. Furthermore I think that the length data type should be modelled after the length data type used in CSS and other W3C standards.

Examples:

ButtonFontHeight 12pt
LabelWidth 20em
TaskbarX 100px
VWMHeight 1.5cm

CSS includes device units (px), font units (em, ex), and physical units (in, cm, mm, pt, pc).

Implementation:

Modules expect units to be pixels, so in order to minimize the changes to the modules LSAPI should provide functions that automatically convert any length to pixels. Such as:

int GetRCWidth(LPCSTR pszKey, HDC hDC, int nDefault);
int GetRCHeight(LPCSTR pszKey, HDC hDC, int nDefault);

These function convert horizontal and vertical lengths, respectively, into pixels. The hDC parameter is used to convert non-device units into device units and may be NULL (in which case the screen DC is used).

Issues:

Trying to make lengths work with expressions is tricky. It can be done, but it will require some work.

http://www.lsdev.org/doku.php?id=lsdev:discussion:displayunits [^]

core

tweak

always

2008-12-31 03:38

2009-01-11 06:21

ilmcuts

none

resolved

none

fixed

AboutBox shows generic icon in taskbar

The !about dialog shows up in the taskbar with a generic icon. It should either show the LiteStep icon or not show up in there at all.

ilmcuts

2009-01-11 06:19

Whether it shows up or not is up to the tasks module.

ilmcuts

2009-01-11 06:20

Fixed in HEAD.

core

major

always

2007-07-16 10:55

2009-01-10 09:34

jugg

ilmcuts

none

resolved

2007-07-08

none

0.24.7

fixed

Vista systray icons are missing

As reported by Chris (Thermo) on LSML:

http://wuzzle.org/archive?4:msp:77199 [^]

The tray is not showing all the icons that are present when I use the exploder as a shell - this includes windows defender, volume, updates, couple others.

I am using systray2 rightnow.

http://wuzzle.org/archive?4:mss:77199 [^]

Found a bit of a working fix for the tray icons

If you download SharpE TD2 from here
http://trac.sharpe-shell.org/wiki/TDSetup [^]

And just run
C:\Sharpe\SharpShellServices.exe

Not the whole shell - just this component - then the missing icons appear in
my Litestep try :)

Weird but functional - would be better if the core or module were fixed.

Chris (Thermo)

ilmcuts

2007-10-08 08:49

The location of the "ShellServiceObjectDelayLoad" stuff has changed. I'm not yet sure if we just need to adjust the location or if the loading procedure is different as well.

ilmcuts

2008-12-31 00:49

At least the network and volume icons are fixed in HEAD, the others I could not check yet. As long as there's no confirmation we'll keep this bug open.

ilmcuts

2009-01-01 10:22

The Windows Defender icon works.

ilmcuts

2009-01-10 09:34

The Windows Update icons appears to work as well. Thus this bug should be fixed.

core

minor

always

2008-12-27 03:36

2009-01-01 10:04

ilmcuts

none

confirmed

none

CVS-trunk

open