Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
63	[litestep modules] vtray.dll	minor	always	2008-12-26 07:38	2009-01-16 16:19
Reporter:	den_po	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Windows Update systray icon does not show
Description:	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.
Steps To Reproduce:
Additional Information:	Windows Update client uses Shell_NotifyIcon with dwMessage unsupported by vtray (NIM_SETFOCUS and NIM_SETVERSION).
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
16	[lsdev.org] general	minor	always	2006-05-06 21:26	2006-05-24 00:12
Reporter:	lsdev	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	The issue Status of "Assigned" does not make sense/ is redundant
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000029) jugg    2006-05-24 00:10	Will change the text "Assigned" to "Accepted".
(0000030) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
85	[litestep core] documentation	text	N/A	2009-01-27 17:42	2009-03-07 06:28
Reporter:	jugg	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	missing build_vc71.txt in CVS
Description:	The build_vc71.txt instructions are missing from the docs folder in CVS HEAD.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000206) 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.
(0000252) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
34	[litestep core] documentation	text	N/A	2007-10-09 17:30	2009-02-28 16:24
Reporter:	jugg	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Decision on LiteStep or Litestep naming convention
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000086) jugg    2008-04-22 02:12	I vote for "LiteStep"
(0000088) Acidfire    2008-04-22 04:46	I also vote "LiteStep". It has more nostalgic value.
(0000099) 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 [^]
(0000106) 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.
(0000107) Acidfire    2008-05-14 16:09	I agree with Tobbe. LiteStep Development Team is consistent.
(0000108) Acidfire    2008-05-14 18:11	Wiki updated to use only LiteStep and LiteStep Development Team.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
46	[litestep core] documentation	text	N/A	2008-04-28 12:39	2009-02-28 16:23
Reporter:	jugg	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	LiteStep 0.24.8 documentation update
Description:	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.
Steps To Reproduce:
Additional Information:	We should also capture the contents of the current math.txt and release_notes.txt in a wiki page on lsdev.org.
Attached Files:

Notes
(0000104) 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
(0000114) 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" - ???
(0000211) 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.
(0000212) 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).
(0000213) 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).
(0000214) jugg    2009-01-31 19:49	Do you have some text to describe !SwitchUser correctly then? I'm not coming up with anything...
(0000215) jugg    2009-01-31 23:31	Ok, I fixed those items.
(0000247) jugg    2009-02-28 15:58	the build docs have been updated, and release_notes.txt renamed to manual.txt. This issue is resolved.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
21	[litestep core] documentation	text	always	2007-03-25 11:15	2008-04-22 13:08
Reporter:	phil	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	CVS instructions not correct on lsdev.org
Description:	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 [^]
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000045) 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.
(0000066) ilmcuts    2007-10-09 13:57	It's now correctly documented here: http://wiki.lsdev.org/doku.php?id=lsdev:cvs [^]
(0000089) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
109	[litestep core] core	tweak	N/A	2010-09-03 15:00	2010-09-03 15:13
Reporter:	alurcard2	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Provide API access to the Wow64FsRedirection functions
Description:	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).
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000277) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
110	[litestep core] core	minor	always	2010-09-03 15:04	2010-09-03 15:04
Reporter:	alurcard2	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Unable to open folders on some systems with the current version os LSExecute/Ex
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
66	[litestep core] core	minor	always	2008-12-28 03:23	2010-09-02 16:41
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Changes to global environment variables have no effect
Description:	Changes to environment variables via sysdm.cpl don't propagate to LiteStep or its child processes.
Steps To Reproduce:
Additional Information:	For implementation hints (WM_SETTINGCHANGE) see http://support.microsoft.com/kb/104011 [^]
Attached Files:

Notes
(0000276) alurcard2    2010-09-02 16:41	You need to reboot your computer for them to update with Explorer as well.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
39	[litestep core] core	minor	always	2008-01-12 08:44	2010-09-01 18:59
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Shortcuts to 64-bit progams broken when running in WOW64
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000101) 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)");
(0000156) ilmcuts    2008-12-31 04:04	Wow64DisableWow64FsRedirection unfortunately does not apply to this specific case.
(0000274) tobbe    2010-08-31 16:05    (edited on: 2010-08-31 16:06)	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.
(0000275) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
108	[litestep core] core	minor	have not tried	2010-08-27 07:26	2010-08-27 07:26
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	ShDocVw.ShellWindows / CreateObject("Shell.Application").Windows does not work
Description:	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 [^]
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
70	[litestep core] core	major	always	2008-12-31 03:55	2010-08-16 03:10
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	64-Bit startup items are not run
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000245) ilmcuts    2009-02-28 06:10	A fix is in CVS. However, I'm not yet convinced that it's fully correct.
(0000272) 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.
(0000273) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
60	[litestep core] core	minor	always	2008-07-23 20:04	2010-08-14 02:27
Reporter:	xjill	Platform:
Assigned To:		OS:
Priority:	none	OS Version:	XP/2000/2003
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Open Containing Folder in Search does nothing
Description:	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.
Steps To Reproduce:	Do a file search in explorer, right click and choose "Open Containing Folder".
Additional Information:
Attached Files:

Notes
(0000151) 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"
(0000221) jugg    2009-02-07 21:41	I can confirm this on Windows 2000 SP4. It makes no difference whether LSUseSystemDDE or LSSetAsShell is enabled.
(0000271) alurcard2    2010-08-14 02:27	The "Open file location" option which essentially replaced this "Open containing folder" works fine on Windows 7

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
61	[litestep core] core	minor	always	2008-07-30 16:19	2010-08-14 02:24
Reporter:	alurcard2	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	The "Status" page for network connections doesn't work while using litestep.
Description:	Trying to open the "Status" page in Control Panel -> Network Connections doesn't do anything while running LS.
Steps To Reproduce:
Additional Information:	It is possible to open it from the system tray however.
Attached Files:

Notes
(0000158) 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.
(0000220) 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$]
(0000222) alurcard2    2009-02-08 11:34	The bug report was based on Windows XP SP3
(0000270) alurcard2    2010-08-14 02:24	This does not seem to be a problem under Windows 7

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
77	[litestep core] core	minor	always	2009-01-12 07:30	2010-08-14 02:16
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Folder Options cannot be opened from Control Panel
Description:	The control panel item "Folder Options" is broken when LiteStep is running. Clicking it has no effect.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000218) jugg    2009-02-07 21:25	I can duplicate this issue on Windows 2000 SP4. What system was this bug originally reported for?
(0000219) 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.
(0000223) 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.
(0000269) alurcard2    2010-08-14 02:16	This also doesn't work on Windows 7.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
53	[litestep core] core	minor	always	2008-06-10 13:02	2010-08-14 02:06
Reporter:	alurcard2	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	The "Find Target" button in shortcut properties doesn't work while using litestep.
Description:	The "Find Target..." button in shortcut properties doesn't work while using litestep.
Steps To Reproduce:	Open the a shortcut properties and click "Find Target..." button. Nothing happens.
Additional Information:	When clicking "Find Target..." a browse for file dialog should open up showing the location of the shortcut target.
Attached Files:

Notes
(0000137) 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.
(0000268) alurcard2    2010-08-14 02:06	This problem does not exist on Windows 7, and therefore probably not on Vista either.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
107	[litestep core] core	feature	always	2010-07-15 05:08	2010-07-15 05:09
Reporter:	MamiyaOtaru	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	handling additional case in trayservice allows correct positioning of vista+ icons
Description:	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 [^]
Steps To Reproduce:
Additional Information:	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
Attached Files:

Notes
(0000267) 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)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
106	[litestep core] core	feature	always	2010-07-15 05:06	2010-07-15 05:06
Reporter:	MamiyaOtaru	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	handling an additional case in trayservice for correct positioning of new vista+ trayicons
Description:	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.
Steps To Reproduce:
Additional Information:	patch attached, affects trayservice cpp and h
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
104	[litestep core] core	feature	have not tried	2010-07-15 05:05	2010-07-15 05:05
Reporter:	MamiyaOtaru	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	handling an additional case in trayservice for correct positioning of new vista+ trayicons
Description:	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.
Steps To Reproduce:
Additional Information:	patch attached, affects trayservice cpp and h
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
103	[litestep core] core	major	always	2009-11-27 23:02	2010-05-04 08:54
Reporter:	Bektash	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	0.24.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Unable to select Microsoft Live Mesh Options
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000264) jugg    2010-05-04 06:58	Please specify what Operating System and systray module and version you are using.
(0000266) 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

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
95	[litestep core] core	feature	always	2009-03-05 15:23	2010-05-04 07:44
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Add fullscreen app notification
Description:	A notification such as a LM_FULLSCREENAPP message should be added to let modules benefit from the core's fullscren app detection code.
Steps To Reproduce:
Additional Information:	#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.
Attached Files:

Notes
(0000265) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
101	[litestep core] core	major	always	2009-11-08 19:12	2010-02-03 15:49
Reporter:	alurcard2	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	WM_SETTINGCHANGE is not sent when the wallpaper slideshow changes wallpaper in Windows 7.
Description:	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.
Steps To Reproduce:
Additional Information:	It should be noted that desktop icon modules (Clickonic, IconDesk, xDesktop) need to repaint their windows when the wallpaper changes as well.
Attached Files:

Notes
(0000263) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
98	[litestep core] core	minor	always	2009-08-13 04:19	2009-11-19 20:38
Reporter:	gravity0	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:	CVS-trunk
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	GCC 4.4 Fix (MathScanner.cpp)
Description:	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.
Steps To Reproduce:
Additional Information:	This isssue can be resolved by adding:   #include <cstdio> in MathScanner.cpp
Attached Files:

Notes
(0000262) jugg    2009-11-19 20:37	Fixed by include stdio.h

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
102	[litestep core] core	crash	always	2009-11-19 19:41	2009-11-19 19:41
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:	0.24.8
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	GetLSBitmapSize crashes when passed a NULL pointer
Description:	GetLSBitmapSize() takes two pointers as parameters, and if passed NULL, it will de-reference the NULL pointer and crash.
Steps To Reproduce:	call GetLSBitmapSize(NULL, NULL, NULL);
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
32	[litestep core] core	block	always	2007-10-09 12:30	2009-07-06 20:23
Reporter:	ilmcuts	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	LiteStep 0.24.8 - Release
Description:	This is a parent issue for all the issues that need to be fixed for 0.24.8.
Steps To Reproduce:
Additional Information:	This is just for issues that exist in the bugtracker. There are many more changes and additions in the actual code.
Attached Files:

Notes
(0000070) 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.
(0000087) 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.
(0000097) 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.
(0000115) 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.
(0000116) 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.
(0000261) jugg    2009-07-06 20:23	not sure why this wasn't issue wasn't marked as closed... doing so now.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
35	[litestep core] core	tweak	always	2007-10-14 07:04	2009-04-20 12:56
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	0.24.7
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	External DLLs cannot be placed in module directory
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000067) 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.
(0000072) 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.
(0000075) 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.
(0000077) 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.
(0000096) 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?
(0000260) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
89	[litestep core] core	crash	always	2009-02-13 13:58	2009-03-15 10:13
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:	0.24.7
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	litestep crashes on recursively included .rc files
Description:	The step.rc preprocessor "Include" statement allows recursively including files and thus crashes with a stack overflow
Steps To Reproduce:	contents of step.rc: Include other.rc contents of other.rc: Include step.rc
Additional Information:
Attached Files:

Notes
(0000259) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
33	[litestep core] core	feature	N/A	2007-10-09 13:31	2009-03-13 18:26
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Provide failsafe behavior in Safe Mode
Description:	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.
Steps To Reproduce:
Additional Information:	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 [^] (?)
Attached Files:

Notes
(0000074) 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.
(0000253) 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.
(0000254) 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.
(0000258) ilmcuts    2009-03-13 18:26	I tend to agree. Bug marked as "fixed". Further improvements will be discussed in Bug 96.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
78	[litestep core] core	minor	always	2009-01-13 13:11	2009-03-13 18:08
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Balloon tip timeout value is not boundary-checked
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000255) 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.
(0000257) ilmcuts    2009-03-13 18:08    (edited on: 2009-03-13 18:10)	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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
13	[litestep core] core	feature	always	2006-05-04 15:42	2009-03-12 18:59
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Logging, please!
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000023) 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?
(0000038) 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.
(0000039) phil    2006-11-11 14:19	s/progress/feedback
(0000061) ilmcuts    2007-07-23 11:45	A logging API shouldn't show message boxes in the first place.
(0000170) 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.
(0000256) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
97	[litestep core] core	minor	always	2009-03-11 08:50	2009-03-11 10:03
Reporter:	jimrandomh	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	XP user switching screen does not show number of tasks
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
96	[litestep core] core	feature	always	2009-03-07 10:39	2009-03-07 10:40
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Improve Safe Mode behavior
Description:	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."
Steps To Reproduce:
Additional Information:	Any such code should be implemented in a separate "failsafe.cpp" file.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
87	[litestep core] core	feature	N/A	2009-01-29 12:38	2009-03-07 06:14
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Add "About LiteStep" and "Switch to Explorer" options in recovery menu
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000251) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
90	[litestep core] core	feature	N/A	2009-02-23 15:55	2009-03-05 15:26
Reporter:	Delf	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-trunk
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none
Summary:	FullScreen app EVENTS
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000228) 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.
(0000229) 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.
(0000240) 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.
(0000241) ilmcuts    2009-02-28 05:22	Take a look at systemevents.dll.
(0000250) ilmcuts    2009-03-05 15:26	The proposed event triggers can be implemented module-side once Bug 95 is resolved.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
36	[litestep core] core	minor	always	2007-10-14 07:15	2009-03-05 15:16
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	0.24.7
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Race condition if modules set error mode
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000068) 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.
(0000145) 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())     { ...

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
86	[litestep core] core	minor	always	2009-01-28 16:07	2009-03-05 15:07
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	0.24.7
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	It is not possible to use a litteral '$' dollar sign in a step.rc text string parameter
Description:	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
Steps To Reproduce:	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
Additional Information:	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?
Attached Files:

Notes
(0000207) 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$
(0000208) 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.
(0000227) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
37	[litestep core] core	minor	always	2007-11-06 13:45	2009-03-05 15:06
Reporter:	jugg	Platform:	Windows
Assigned To:		OS:	2000 Professional
Priority:	none	OS Version:	SP4
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	ABM_GETTASKBARPOS returns incorrect information
Description:	ABM_GETTASKBARPOS should return the position of the TaskBar not the SystemTray.
Steps To Reproduce:
Additional Information:	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.
System Description	Windows 2000 Professional Service Pack 4
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
73	[litestep core] core	minor	always	2009-01-03 11:22	2009-03-05 15:05
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	LS desktop does not interact with Vista's new ALT-TAB
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:	testdesktop.7z (27 KB) 2009-01-10 15:44

Notes
(0000162) 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?
(0000166) 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.
(0000175) ilmcuts    2009-01-16 15:32	Replicating Explorer's window hierarchy makes the thumbnail work.
(0000249) ilmcuts    2009-03-05 15:05	No longer a "mystery bug" because we should be able to work out a fix now.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
94	[litestep core] core	tweak	always	2009-03-05 15:01	2009-03-05 15:01
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Message loops should call CallMsgFilter
Description:	All message loops should call CallMsgFilter. This simplifies thread message handling and leaves fewer opportunities for subtle bugs.
Steps To Reproduce:
Additional Information:	Among other things, this enables modules to inject IsDialogMessage calls onto the main thread as needed.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
93	[litestep core] core	tweak	always	2009-03-05 14:58	2009-03-05 14:58
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Remove 'threaded' module flag
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
27	[litestep core] core	minor	always	2007-07-13 16:54	2009-03-05 14:44
Reporter:	jugg	Platform:	Windows
Assigned To:		OS:	2000 Professional
Priority:	none	OS Version:	SP4
Status:	feedback	Product Version:	0.24.7
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Startup items are not synchronized with the shell initialization correctly
Description:	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.
Steps To Reproduce:
Additional Information:	--------------------------------------------------------------------------------  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 --------------------------------------------------------------------------------
System Description	Windows 2000 Professional Service Pack 4
Attached Files:

Notes
(0000152) 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"

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
52	[litestep core] core	major	always	2008-06-02 11:17	2009-03-05 14:42
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	LCReadNextCommand/Config/Line implementations are broken.
Description:	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.
Steps To Reproduce:	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.
Additional Information:	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.
Attached Files:

Notes
(0000129) 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.
(0000242) 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".
(0000248) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
49	[litestep core] core	major	always	2008-05-12 18:41	2009-03-05 14:41
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	expansion of $e-var$ does not expand to the full value of the e-var
Description:	When calling VarExpansionEx(), the result does not contain the entire value of the variable as it was defined.
Steps To Reproduce:	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.
Additional Information:	This needs to be handled with care as any change will likely affect/break many existing modules and configurations.
Attached Files:

Notes
(0000210) 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()

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
48	[litestep core] core	major	always	2008-05-12 18:30	2009-03-05 14:41
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	LSGetVariable() does not return value set by LSSetVariable()
Description:	When calling LSSetVariable with an unquoted value containing whitespace, subsequently calling LSGetVariable only returns the first "word" of the value.
Steps To Reproduce:	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.
Additional Information:	The solution will likely affect many modules and configurations. This needs to be handled with care.
Attached Files:

Notes
(0000150) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
24	[litestep core] core	minor	always	2007-06-26 19:25	2009-03-05 14:40
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:	0.24.7
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	TrayService Shared Icons are not implemented fully/correctly
Description:	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).
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
20	[litestep core] core	major	N/A	2006-11-06 15:03	2009-03-05 14:37
Reporter:	jugg	Platform:	Windows
Assigned To:		OS:	2000 Professional
Priority:	none	OS Version:	SP4
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	TCHAR/char mix-match throughout code base
Description:	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.
Steps To Reproduce:
Additional Information:
System Description	Windows 2000 Professional Service Pack 4
Attached Files:

Notes
(0000095) 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?
(0000109) 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.
(0000111) 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.
(0000112) 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.
(0000134) ilmcuts    2008-07-19 12:26    (edited on: 2008-07-19 12:27)	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).
(0000239) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
92	[litestep core] core	block	always	2009-03-05 14:36	2009-03-05 14:36
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	LiteStep 0.26.0 - Release
Description:	This is a parent issue for all the issues that need to be fixed for 0.26.0.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3	[litestep core] core	major	always	2006-04-26 15:11	2009-02-28 16:27
Reporter:	phil	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	fixed
Projection:	minor fix
ETA:	none
Summary:	$expressions$ always calculate as floats. Compatibility issue with 0.24.7 that provided ints.
Description:	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.
Steps To Reproduce:	something like : myVar1 "18" myVar2 "13" will cause $(myVar1 - myVar2)/2$ to report 2.5 instead of 2 (as provided by integer()).
Additional Information:
Attached Files:	MathValue.cpp.patch (1 KB) 2006-05-03 12:52 MathEvaluateString.patch (2 KB) 2006-05-23 19:19

Notes
(0000009) 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
(0000010) 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?
(0000013) phil    2006-05-03 11:59	Is there an obvious place in the code to fix this ahead of an officially sanctioned patch? :)
(0000014) 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.
(0000015) 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.
(0000017) 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).
(0000028) 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.
(0000035) 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?
(0000036) 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.
(0000041) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1	[litestep core] core	minor	always	2006-03-09 16:38	2009-02-28 16:26
Reporter:	jugg	Platform:	Windows
Assigned To:	jugg	OS:	2000 Professional
Priority:	none	OS Version:	SP4
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Platform evars are only set to true, never false
Description:	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.
Steps To Reproduce:	execute from lsxcommand: !alert $Win98$ When on a different platform than Windows 98 this will produce an undefined variable error message.
Additional Information:	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.
System Description	Windows 2000 Professional Service Pack 4
Attached Files:

Notes
(0000001) 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.
(0000002) 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.
(0000003) 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.
(0000004) 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.
(0000042) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
9	[litestep core] core	crash	always	2006-04-29 10:55	2009-02-28 16:26
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	minor fix
ETA:	< 1 day
Summary:	GetToken might crash in unlikely cases
Description:	GetToken calls strlen(NULL) if pszToken is NULL and concatenation is used. This is a rare combination however.
Steps To Reproduce:
Additional Information:
Attached Files:	lsapi.cpp.patch (1 KB) 2006-04-29 11:01

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
19	[litestep core] core	minor	always	2006-10-31 23:06	2009-02-28 16:26
Reporter:	jugg	Platform:	Windows
Assigned To:	jugg	OS:	2000 Professional
Priority:	none	OS Version:	SP4
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	"Dead" notification (systray) icons reappear on recycle
Description:	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.
Steps To Reproduce:	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.
Additional Information:	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)
System Description	Windows 2000 Professional Service Pack 4
Attached Files:

Notes
(0000033) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
23	[litestep core] core	minor	always	2007-06-11 10:08	2009-02-28 16:25
Reporter:	jugg	Platform:	Windows
Assigned To:	jugg	OS:	2000 Professional
Priority:	none	OS Version:	SP4
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Semicolon following ELSE or ENDIF statment breaks parser
Description:	Placing a semicolon immediately after an ELSE or ENDIF statement (with no whitespace) breaks the step.rc file parser.
Steps To Reproduce:	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.
Additional Information:	Thanks to fractal.design for finding and pointing out this bug. See http://lsdev.org/e107_plugins/forum/forum_viewtopic.php?1202 [^]
System Description	Windows 2000 Professional Service Pack 4
Attached Files:	SettingsFileParser.cpp.patch (1 KB) 2007-06-26 13:33

Notes
(0000057) 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.
(0000059) jugg    2007-07-08 12:40	Fixed. Code is in CVS.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
26	[litestep core] core	minor	always	2007-07-09 10:49	2009-02-28 16:25
Reporter:	jugg	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	The !about command can launch multiple concurrent About dialogs.
Description:	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.
Steps To Reproduce:	Execute !bang more than once without closing previous instances of the About dialog.
Additional Information:
Attached Files:

Notes
(0000062) ilmcuts    2007-07-31 17:20	Fixed both in branch and HEAD. Thanks to Acidfire for submitting a patch on the lsdev list.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
30	[litestep core] core	minor	always	2007-10-06 09:17	2009-02-28 16:25
Reporter:	ilmcuts	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	AppBar space from crashed apps is never released
Description:	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]
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000069) jugg    2007-11-06 13:11	I'm working on this.
(0000084) 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.
(0000091) jugg    2008-04-24 10:54	Code has been merged into the 024x branch.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
5	[litestep core] core	minor	always	2006-04-27 19:40	2009-02-28 16:24
Reporter:	jugg	Platform:	Windows
Assigned To:	jugg	OS:	2000 Professional
Priority:	none	OS Version:	SP4
Status:	closed	Product Version:	CVS-024x
Product Build:	2006-03-30	Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Nested If/Endif with invalid expression syntax causes incorrect conditional block evaluation.
Description:	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.
Steps To Reproduce:	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
Additional Information:	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.
System Description	Windows 2000 Professional Service Pack 4
Attached Files:	SettingsFileParser.cpp.patch (1 KB) 2006-04-27 19:40

Notes
(0000031) jugg    2006-05-24 00:35	I guess I'll go ahead and take this one on, and apply the patch to CVS.
(0000032) jugg    2006-05-24 00:48	Patch committed to CVS (including a debug TRACE message)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
10	[litestep core] core	trivial	have not tried	2006-05-04 14:54	2009-02-28 16:24
Reporter:	phil	Platform:
Assigned To:	Acidfire	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Build date in !about is not updating (month)
Description:	Building LS today, the month in the compile date is reported as April in the !about box. No idea why yet.
Steps To Reproduce:
Additional Information:
Attached Files:	compile_time.patch (2 KB) 2007-11-06 13:17 compile_time2.patch (3 KB) 2008-04-28 11:22

Notes
(0000019) 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.
(0000027) 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.
(0000037) 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.
(0000063) ilmcuts    2007-10-06 10:34	To fix this for good we can read the build date from litestep.exe's PE header.
(0000071) jugg    2007-11-06 13:17	Adding patch from Acidfire
(0000079) Acidfire    2008-02-12 03:21	Now fixed in head. This bug can be closed.
(0000098) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
43	[litestep core] core	tweak	always	2008-04-22 12:34	2009-02-28 16:23
Reporter:	jugg	Platform:
Assigned To:	tobbe	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	LSAutoHideModules doesn't show/hide modules when it should (CVS-024x)
Description:	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.
Steps To Reproduce:	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
Additional Information:	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); }
Attached Files:	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

Notes
(0000092) tobbe    2008-04-24 14:04	The patch uses GetWindowPlacement instead of GetWindowRect
(0000093) jugg    2008-04-25 11:05    (edited on: 2008-04-25 11:07)	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.
(0000102) 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);
(0000117) 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.
(0000118) jugg    2008-06-08 14:41	It works fine with VLC for me.
(0000119) 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.
(0000141) 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.
(0000142) 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.
(0000146) tobbe    2008-08-19 13:39	jugg's latest patch seems to fix all reported problems
(0000147) tobbe    2008-08-19 13:45	jugg's latest patch seems to fix all reported problems

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
50	[litestep core] core	tweak	always	2008-05-12 18:48	2009-02-28 16:23
Reporter:	jugg	Platform:
Assigned To:	Acidfire	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	$CompileDate$ can be incorrect
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000105) Acidfire    2008-05-14 11:00	Fixed in both head and branch.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
57	[litestep core] core	major	always	2008-06-16 12:54	2009-02-28 16:22
Reporter:	paokaoru	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	At 0.24.8-RC1, tray icons' balloontips can't be viewed
Description:	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.)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000128) 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.
(0000131) 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.
(0000144) 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?
(0000165) 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.
(0000169) 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.
(0000186) 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.
(0000187) 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.
(0000188) jugg    2009-01-21 11:28	The fix has been committed to CVS 024x.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
62	[litestep core] core	major	N/A	2008-08-15 13:38	2009-02-28 16:22
Reporter:	jugg	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Backport major bug fixes from HEAD to the 024x branch
Description:	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.
Steps To Reproduce:
Additional Information:	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
Attached Files:

Notes
(0000143) jugg    2008-08-18 01:43	I will re-open this issue if necessary. For now marking as resolved.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
58	[litestep core] core	minor	always	2008-07-01 11:54	2009-02-28 16:21
Reporter:	klingens	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	!about box system information does not display above 2gig of memory
Description:	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
Steps To Reproduce:	Have 4GB of ram installed, and show the !about box system information page.
Additional Information:	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 :)
Attached Files:

Notes
(0000138) 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.
(0000149) jugg    2008-08-19 17:12    (edited on: 2008-08-19 17:38)	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
(0000159) 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.
(0000160) 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 [^]
(0000185) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
79	[litestep core] core	minor	always	2009-01-13 22:09	2009-02-28 16:21
Reporter:	jugg	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	The v0-24-x branch mingw makefile does not successfully compile the source code
Description:	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.
Steps To Reproduce:	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
Additional Information:
Attached Files:

Notes
(0000205) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
67	[litestep core] core	feature	always	2008-12-29 11:19	2009-02-28 16:21
Reporter:	tobbe	Platform:	Windows
Assigned To:	jugg	OS:	XP Professional
Priority:	none	OS Version:	SP2
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	LiteStep only reports full gigabytes of memory
Description:	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
Steps To Reproduce:
Additional Information:
System Description	Windows EP Professional Service Pack 2
Attached Files:

Notes
(0000154) 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.
(0000183) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
38	[litestep core] core	minor	always	2008-01-10 06:41	2009-02-28 16:21
Reporter:	ilmcuts	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Re-entrancy issues in TrayService
Description:	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.
Steps To Reproduce:
Additional Information:	See http://blogs.msdn.com/oldnewthing/archive/2004/06/08/150929.aspx [^]
Attached Files:	appbarcreator.zip (8 KB) 2008-04-25 11:28

Notes
(0000078) ilmcuts    2008-01-10 06:44    (edited on: 2008-01-10 06:45)	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.
(0000080) 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.
(0000085) 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.
(0000094) 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.
(0000237) jugg    2009-02-23 22:10	Fix committed to both HEAD and 0-24-x branch.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
71	[litestep core] core	minor	always	2008-12-31 04:12	2009-02-28 16:20
Reporter:	ilmcuts	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	ABM_GETTASKBARPOS needs to set uEdge on return
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000236) jugg    2009-02-23 22:10	Fix committed to both HEAD and 0-24-x branch.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
75	[litestep core] core	minor	always	2009-01-11 06:29	2009-02-28 06:12
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	unable to reproduce
Projection:	none
ETA:	none
Summary:	Handle leak in AboutBox
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000174) 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.
(0000246) ilmcuts    2009-02-28 06:12	I cannot reproduce this any more either. Bug closed and marked as "unable to reproduce".

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
47	[litestep core] core	trivial	always	2008-05-06 08:59	2009-02-28 05:44
Reporter:	Acidfire	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	!runstartups to use when LSNOSTARTUP is set
Description:	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."
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000136) 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?
(0000140) 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?
(0000179) 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.
(0000180) 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.
(0000182) 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).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
11	[litestep core] core	feature	always	2006-05-04 15:05	2009-02-28 05:43
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-trunk
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none
Summary:	includefolder patch for CVS
Description:	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.
Steps To Reproduce:
Additional Information:	All credit to ilmcuts for developing this for LDE(X) over IRC :)
Attached Files:	SettingsFileParser.cpp.patch (2 KB) 2006-05-04 15:05

Notes
(0000018) 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.
(0000021) jugg    2006-05-06 20:20	Thanks for the patch, we'll take a look at it.
(0000046) 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"?
(0000050) 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
(0000051) phil    2007-06-12 06:44	Yeah. I documented the patches in that PDF. Apologies for the oversight in the original submission.
(0000054) jugg    2007-06-12 10:33	I have the code merged locally. Just need to commit to CVS after testing.
(0000056) 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.
(0000225) phil    2009-02-13 12:16	Could this be enabled by default?
(0000232) jugg    2009-02-23 21:09	Removing from 024.8 release as it will not be enabled by default for said release.
(0000243) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
51	[litestep core] core	major	always	2008-05-16 12:34	2009-02-23 22:16
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-trunk
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none
Summary:	GetRCLine() incorrectly returns parsed value
Description:	When calling GetRCLine(), the returned value has any contained e-vars already expanded. This should not be. GetRCLine() should return a "raw" value.
Steps To Reproduce:	char tmp[128]; LSSetVariable("MyVar", "Hello"); LSSetVariable("MyLine" "$MyVar$"); GetRCLine("MyLine", tmp, 128, ""); Inspect "tmp". It will contain "Hello" rather than "$MyVar$".
Additional Information:	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.
Attached Files:

Notes
(0000110) 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.
(0000113) 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.
(0000238) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
41	[litestep core] core	tweak	always	2008-04-14 11:39	2009-02-23 21:45
Reporter:	tobbe	Platform:	Windows
Assigned To:	jugg	OS:	XP Professional
Priority:	none	OS Version:	SP2
Status:	resolved	Product Version:	CVS-trunk
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	LSAutoHideModules doesn't show/hide modules when it should (CVS-trunk)
Description:	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.
Steps To Reproduce:	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
Additional Information:
System Description	Windows EP Professional Service Pack 2
Attached Files:	litestep.patch (6 KB) 2008-04-17 14:36

Notes
(0000081) 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.
(0000082) 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); }
(0000083) 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.
(0000148) tobbe    2008-08-19 13:52	Need to port the code from 0.24.x. It needs to be updated to support multiple monitors.
(0000184) 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.
(0000198) jugg    2009-01-24 22:50    (edited on: 2009-01-24 22:52)	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.
(0000235) jugg    2009-02-23 21:45	This was resolved in CVS on "Thu Jan 22 03:19:57 2009 UTC".

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
8	[litestep core] core	minor	always	2006-04-29 05:10	2009-02-23 21:21
Reporter:	ilmcuts	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:	CVS-trunk
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	The SDK's include/lsapi.h and core lsapi declarations of LC* functions are different.
Description:	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*.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000016) 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.
(0000020) 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?
(0000049) jugg    2007-05-07 18:19    (edited on: 2007-11-06 20:52)	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.
(0000234) 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."

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
81	[litestep core] core	trivial	N/A	2009-01-23 11:15	2009-02-23 21:19
Reporter:	jugg	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:	CVS-trunk
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Stub out win95 specific multi-monitor functions.
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000233) 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"

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
84	[litestep core] core	feature	always	2009-01-27 09:43	2009-02-16 22:30
Reporter:	jimrandomh	Platform:
Assigned To:	Acidfire	OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Path separation functions in evar expansions
Description:	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
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000204) 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?
(0000209) 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?
(0000224) Acidfire    2009-02-13 04:28	How about before_first, before_last, after_first and after_last?
(0000226) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
76	[litestep core] core	trivial	always	2009-01-12 06:29	2009-02-07 21:21
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	not fixable
Projection:	none
ETA:	none
Summary:	Minimized Task Manager does not disappear from taskbar
Description:	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.
Steps To Reproduce:
Additional Information:	This could be a bug in the taskbar module, in my case taskbar3 0.306 alpha 3 (sic).
Attached Files:

Notes
(0000176) ilmcuts    2009-01-16 16:27	According to alur, this happens with xtaskbar as well
(0000177) 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?
(0000178) ilmcuts    2009-01-16 17:16	I'm on Vista. Setting LSSetAsShell fixes this. Dependency Walker reveals that Task Manager imports GetShellWindow.
(0000181) alurcard2    2009-01-17 11:31	I'm on XP, and LSSetAsShell fixes it here as well.
(0000217) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
88	[litestep core] core	minor	always	2009-02-03 13:44	2009-02-07 21:19
Reporter:	Delf	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-trunk
Product Build:		Resolution:	not fixable
Projection:	none
ETA:	none
Summary:	Unable to map hotkey when LSSetAsShell TRUE
Description:	Using anykey.dll (1.0) it is not possible to map keys CTRL ESCAPE when LSSetAsShell TRUE is set.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000216) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
74	[litestep core] core	feature	always	2009-01-09 20:05	2009-01-27 09:54
Reporter:	crazy2be	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none
Summary:	Add $litestepdrive$ functionality to the core
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000203) Acidfire    2009-01-27 09:53	The requested functionality will be covered by the solution to bug 0000084 (see relationship).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
83	[litestep core] core	major	always	2009-01-25 13:39	2009-01-25 13:55
Reporter:	jimrandomh	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	SendMessageTimeout(WM_GETICON) causes Litestep to lock up whenever an app stops handling messages
Description:	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).
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000202) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
45	[litestep core] core	feature	N/A	2008-04-25 15:52	2009-01-25 13:29
Reporter:	jugg	Platform:
Assigned To:	tobbe	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Use LodePNG for png image support
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000168) ilmcuts    2009-01-10 09:41	picoPNG is now enabled by default on HEAD.
(0000173) ilmcuts    2009-01-11 06:31	The change was reverted. According to alur, the PNGs appear inverted.
(0000199) 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.
(0000200) 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 [^]
(0000201) tobbe    2009-01-25 13:29	Support has been added for transparency.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
80	[litestep core] core	minor	always	2009-01-22 21:12	2009-01-24 22:50
Reporter:	jimrandomh	Platform:
Assigned To:	tobbe	OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Transparent fullscreen apps hide modules
Description:	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.)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000189) jugg    2009-01-23 08:53    (edited on: 2009-01-23 08:54)	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. :)
(0000195) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
82	[litestep core] core	feature	always	2009-01-23 11:39	2009-01-23 12:36
Reporter:	tobbe	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Preprocessor additions
Description:	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
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000190) 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.
(0000191) 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.
(0000192) 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.)
(0000193) 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.
(0000194) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
68	[litestep core] core	minor	always	2008-12-29 11:48	2009-01-16 16:23
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Compatibility - Mystery Bugs
Description:	This is a parent issue for compatibility issues that have no obvious fix and/or require LiteStep to support undocumented behavior.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000163) jugg    2009-01-03 23:12	Please be sure to specify your OS version when reporting these types of bugs!

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
40	[litestep core] core	minor	always	2008-01-13 12:41	2009-01-16 16:20
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Implement Vista changes to NOTIFYICONDATA
Description:	The NOTIFYICONDATA struct has a few new flags and a new member, hBalloonIcon. We're probably leaking the latter currently.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
17	[litestep core] core	feature	N/A	2006-06-05 13:00	2009-01-16 16:20
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-024x
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Merge sidestep features for advanced image handling
Description:	http://eric.redtetrahedron.org/readme.htm [^] Source is available, but patch generation is awkward due to invasive nature of changes across LS code.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000048) jugg    2007-05-07 18:18	We will look into it.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
25	[litestep core] core	feature	N/A	2007-06-28 10:00	2009-01-16 16:20
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	0.24.7
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	ExecuteAndWait support
Description:	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 [^]
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000058) 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)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
55	[litestep core] core	feature	N/A	2008-06-13 11:40	2009-01-16 16:18
Reporter:	maduin	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Lengths, Units, and Resolution Independence
Description:	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.
Steps To Reproduce:
Additional Information:	http://www.lsdev.org/doku.php?id=lsdev:discussion:displayunits [^]
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
69	[litestep core] core	tweak	always	2008-12-31 03:38	2009-01-11 06:21
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	AboutBox shows generic icon in taskbar
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000171) ilmcuts    2009-01-11 06:19	Whether it shows up or not is up to the tasks module.
(0000172) ilmcuts    2009-01-11 06:20	Fixed in HEAD.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
28	[litestep core] core	major	always	2007-07-16 10:55	2009-01-10 09:34
Reporter:	jugg	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:	0.24.7
Product Build:	2007-07-08	Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Vista systray icons are missing
Description:	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.
Steps To Reproduce:
Additional Information:	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)
Attached Files:

Notes
(0000065) 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.
(0000155) 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.
(0000157) ilmcuts    2009-01-01 10:22	The Windows Defender icon works.
(0000167) ilmcuts    2009-01-10 09:34	The Windows Update icons appears to work as well. Thus this bug should be fixed.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
64	[litestep core] core	minor	always	2008-12-27 03:36	2009-01-01 10:04
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:	CVS-trunk
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Recent Documents is broken
Description:	The special folder "Recent Documents" is not updated any more when LiteStep is the shell.
Steps To Reproduce:
Additional Information:	Apparently, without Explorer SHAddToRecentDocs becomes a nop.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
72	[litestep core] core	minor	always	2009-01-01 10:02	2009-01-01 10:03
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Printer status icon never shows up
Description:	The printer status icon never shows up when LiteStep is running.
Steps To Reproduce:
Additional Information:	http://support.microsoft.com/kb/310578 [^] According to the above, it curiously is the shell that implements the icon.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
65	[litestep core] core	minor	always	2008-12-27 03:41	2008-12-30 09:47
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Vista's new ALT-TAB dialog does not work
Description:	Windows Vista includes an updated ALT-TAB dialog that does not appear when LiteStep is the shell. Instead, the classic ALT-TAB dialog is displayed.
Steps To Reproduce:
Additional Information:	There is a ShellServiceObject that is responsible for the new dialog. Blindly loading it can lead to LiteStep crashing on startup.
Attached Files:

Notes
(0000153) ilmcuts    2008-12-30 09:47	Fixed in HEAD.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
59	[litestep core] core	minor	always	2008-07-20 16:51	2008-07-23 18:57
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Some system sounds aren't being played on XP and Vista
Description:	On both XP and Vista, the logon and logoff sounds aren't being played when the screen is locked/unlocked respectively. On Vista, the logon sound also isn't played on startup.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000139) ilmcuts    2008-07-23 18:57	Fixed in HEAD.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
29	[litestep core] core	major	always	2007-07-16 10:58	2008-07-20 17:14
Reporter:	jugg	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:	0.24.7
Product Build:	2007-07-08	Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Vista startup items are run twice
Description:	As reported by Chris (Thermo) on LSML: http://wuzzle.org/archive?4:msp:77199 [^] The items in my user startup folder try to open twice when I have litestep as my shell.
Steps To Reproduce:
Additional Information:	This does not happen if I run a really old build of litestep instead of the current ones. If I use -nostartup to start Litestep - nothing launches at all.
Attached Files:

Notes
(0000064) ilmcuts    2007-10-08 08:39	The problem is that on Vista, CSIDL_COMMON_ALTSTARTUP and CSIDL_ALTSTARTUP resolve to the same directories as CSIDL_COMMON_STARTUP and CSIDL_STARTUP, respectively. Since there is no equivalent to the ALT versions on Vista, simply skipping them should be all.
(0000135) ilmcuts    2008-07-20 17:14	Fixed in HEAD.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
54	[litestep core] core	minor	always	2008-06-10 22:37	2008-07-01 12:08
Reporter:	crazy2be	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	no change required
Projection:	none
ETA:	none
Summary:	Relative Paths not working correctly
Description:	If you set a var as a relitive path, them use that relitive path in a popup entry, the program fails to execute. AnApp "..\this\will\not\execute\if\you\try.exe" *Popup "An App" "$AnApp$" using xpopup 2.0.5, the icon will appear correctly, but the program will not execute on click.
Steps To Reproduce:
Additional Information:	AnApp "$Litestepdir$\..\this\will\not\execute\if\you\try.exe" does not work either, and xpopup fails to correctly assign an icon (there is none)
Attached Files:

Notes
(0000120) jugg    2008-06-11 14:46	What would be your expected functionality? I do not consider this a bug. It has always been required that one uses absolute paths. If you want xPopup to specifically support relative paths, then you'll need to contact Andymon over at ls-universe. If you'd like to see relative paths supported in the core of LS, please explain how you'd expect this to work.
(0000121) crazy2be    2008-06-11 18:20	my expected functionality would be that the app would be executed relitive to the litestep dir. xPopup dose seem to support relitive paths, at least partially. the first example will find the correct icon, but will not execute the app when clicked. i'm not sure how the app execution works, but i would assume that the module sends a request to the core in order to execute the app, and this core does not understand relitive paths. "..\this\will\not\execute\if\you\try.exe" should go one directory up from the litestepdir, then search for the path from there. i considered this to be a bug because of partial functionality. (the icon works, but the app does not exectue.)
(0000122) jugg    2008-06-13 09:16	Well, I see two cases here: 1. Relative below (sub directory of) the LiteStep directory, in which case just prepend the path with $LiteStepDir$ making this irrelevant. 2. Relative above the LiteStep directory, in which case it isn't portable, and you already know the absolute path that you are trying to get to. The only use case I see Number 2 needing relative paths is in the case of putting LS on a portable device in which case the drive letter changes, thus an absolute path would be difficult to dynamically determine. A solution would be to parse out the drive letter from $LiteStepDir$, then create your path based on that. Or you can have a batch file that launches LiteStep, and also sets an environment variable containing the path. Anyway, I still don't see that relative paths as in Number 2 belongs in the core. Please explain why what you are trying to do should be solved in this manner. As far as inconsistencies in xPopup, please report them to ls-universe, this is not the place for it.
(0000123) crazy2be    2008-06-14 18:56	I am using this on a portable device, and made a batch file after asking for help from a few people. i would like to see this in the core so that is is easier to set relative paths, without having to launch LS using a batch file. and as for the inconsistencies in xpopup, i am reporting them here, since xpopup HAS the expected functionality and the core does not. it would be silly to ask andymon to remove useful functionality, don't you agree?
(0000124) jugg    2008-06-16 07:33	Get ahold of me on IRC so we can talk this out. I don't see the draw back of needing to launch a batch file to setup the necessary environment in your use case.
(0000127) Acidfire    2008-06-16 13:02	AnApp "$Litestepdir$\..\this\will\not\execute\if\you\try.exe" doesn't work. Try doing an !alert on that and you'll see why. "$Litestepdir$..\this\will\not\execute\if\you\try.exe" works perfectly...
(0000130) Acidfire    2008-06-18 08:30	Closed because relative paths already work. If a case is found where relative paths don't work not due to a user error, this issue can be reopened.
(0000132) crazy2be    2008-06-21 10:32	I think that $LitestepDrive$ would be a useful var and should be added. so perhaps this should be placed in the "feature" category, since the original issue was found to be user error :P with "$LitestepDrive$" as a var, is makes is much easier to run litestep portability. although i get the same functionality with a batch file, it would be nice to have the feature within the core itself, so that one can easily reference an app on the same drive as litestep.
(0000133) jugg    2008-07-01 12:08	Please open a new feature request ticket for $LitestepDrive$ functionality.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
12	[litestep core] core	feature	N/A	2006-05-04 15:19	2008-04-28 15:31
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:	CVS-024x
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	DumpVariables patch
Description:	This is a series of patches for !DumpVariables
Steps To Reproduce:
Additional Information:	All credit to ilmcuts, as ever :)
Attached Files:	SettingsManager.cpp.patch (1 KB) 2006-05-04 15:19 bangs.cpp.patch (1 KB) 2006-05-04 15:22 bangs.h.patch (0 KB) 2006-05-04 15:23 SettingsManager.h.patch (0 KB) 2006-05-04 15:34

Notes
(0000022) jugg    2006-05-06 20:20	Thanks for the patch, we'll take a look at it.
(0000100) jugg    2008-04-28 15:31	This would be more interesting if the !DumpVariables bang could take a parameter which might specify the target to dump to. ie. the file to dump the variables to, or to dump to the clipboard, or whatever other feasible location there might be. The current patch defaults to a hardcoded location if the DumpFile directive is not specified, having a separate directive isn't a suitable implementation, nor is a default file path/name. If any updated patch is supplied with a more suitable implementation, I think this would be a good feature to add.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
31	[litestep core] core	minor	always	2007-10-06 09:32	2008-04-22 13:20
Reporter:	ilmcuts	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	not fixable
Projection:	none
ETA:	none
Summary:	AppBars are 'lost' on litestep.exe restart
Description:	Any existing AppBars are forgotten by the core the moment litestep.exe (more specifically, the desktop module) exits.
Steps To Reproduce:
Additional Information:	There is no equivalent to the 'TaskbarCreated' message for AppBars (nor are apps required to re-register AppBars in response to that message for some reason).
Attached Files:

Notes
(0000073) jugg    2007-11-06 13:59	Nothing prevents AppBars from responding to 'TaskbarCreated'. IMO they should, and it is just as a sufficient mechanism for AppBars as it is for TrayIcons. I don't think this is a valid bug report against Litestep. My suggestion is to file a bug report with whatever application that is displaying the AppBar, and suggest to them to respond to the 'TaskbarCreated' notification. So unless someone argues differenetly, I'm will mark this issue as invalid/won't fix and close it.
(0000090) jugg    2008-04-22 13:20	This issue is not fixable internally to LiteStep. AppBars must re-add themselves when the shell restarts. They can know this by registering for the 'TaskbarCreated' message. As for they AppBars space being 'lost' when the desktop module is unloaded, I can't confirm this any longer since issue 0000030 has been fixed.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
42	[litestep core] core	block	always	2008-04-22 12:12	2008-04-22 12:13
Reporter:	jugg	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	LiteStep 0.25.0 - Release
Description:	This is a parent issue for all the issues that need to be fixed for 0.25.0.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
22	[litestep core] core	feature	always	2007-03-25 12:26	2007-06-24 14:09
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	0.24.7
Product Build:		Resolution:	no change required
Projection:	none
ETA:	none
Summary:	No way to safely query a variable that might not exist
Description:	If I want to query whether a variable exists or not, without erroring if it doesn't exist, LS doesn't provide a method to do this. For example, if I want to know whether MYEVAR exists, in mzScript I can do : !ifeval ["$MYEVAR$" = ""] [!dothis] however, the query against MYEVAR will fail if the variable doesn't exist. This error comes from LS itself, where mzScript passes the variable through to the core for expansion. This tends to panic the user and wreck some elements of our preference save/load code (which walks an array of setting names, which may or may not exist - we don't care) In fact, I may well not care whether MYEVAR is actually defined - I just want to know whether it is or not. I'd like to extend the expansion code with a 'silent' mode that doesn't alert. Sadly,
Steps To Reproduce:
Additional Information:	I'd like to try and patch this myself, but with the CVS problems, I cannot pull the latest source.
Attached Files:

Notes
(0000044) jugg    2007-05-05 14:22	Can you use the defined() function evaluator? (ie. see math.txt)
(0000052) phil    2007-06-12 06:46	Ahah. I'd not looked at that side of things. Possibly. How stable is that implementation? I'd hate to use it, only to have it ripped out again.
(0000053) jugg    2007-06-12 10:29    (edited on: 2007-06-12 10:31)	Stable. It'll at least be in all subsequent 0.24.x releases. Please let me know if the defined() solution is sufficient, or if something else needs addressed/fixed.
(0000055) jugg    2007-06-24 14:09	Closing issue, as the desired functionality already exists in the 0.24.x code.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
18	[litestep core] core	feature	N/A	2006-08-01 13:13	2007-05-07 18:15
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none
Summary:	Proxy in Evar support
Description:	It would be very useful to have an Evar (or two) to pull in the current proxy settings from Windows. An example of a module where this would be useful is GoogleCalc. e.g. $proxy$ $proxyport$ ; needed if $proxy$ does not yield proxy:port
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000047) jugg    2007-05-07 18:14	There is non reason this could not be done by a module. I see no reason to put it into the core, as it does not relate to any core requirement or use. Nor is there any current code base in the core that this could be easily obtained from.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
14	[litestep core] core	minor	always	2006-05-04 15:45	2007-01-23 00:59
Reporter:	phil	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	won't fix
Projection:	major rework
ETA:	none
Summary:	More informative error dialogs, please
Description:	The current code only reports an error. It does not help to locate the source of the error. The error dialog should, if possible, give as much of the following as possible. This should also be integrated with the logging system when dialogs are suppressed. - Full line of code that broke - Some idea of why it broke - File in which the line of code was located, along with line number OR if that is not possible, some context code from either side to help locate the problem
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000024) jugg    2006-05-06 20:24	I want to try to get file name and line number added to the error dialogs for 0.24.8 if possible. This is definitely an issue, and we'll try to work on it.
(0000025) jugg    2006-05-06 20:27	I'm updating the issue severity to "minor" instead of "feature", because I view this as a bug. It really is pointless throwing up an error box that doesn't help the user fix the problem. I see this as a high priority item for 0.24.8 release.
(0000034) jugg    2006-11-04 19:28	Ok, as I worked through this item, I've implemented informative TRACE messages in the DEBUG build for tracking what files are being parsed, and how If/ElseIF statements are evaluated, and any problems that occur during the initialize read/parse of the configuration files. The output includes line numbers and file names on where syntax problems and errors occur. However, I believe the majority of the problems that users encounter, are during runtime EVAR expansion. These expansions have no context, and therefor can not have any precision in regards to the location of the error. So, we can only try as best as possible to present what is wrong, but in this situation we are unable to present where the problem is located in the configuration files. To do this would require meta data being associated with the stored directives, which is not a feasible solution.
(0000043) jugg    2007-01-23 00:59	While progress has been made in the code to provide more informative Debug TRACE messages, the end user Error dialogs at this point can not be updated to provide anything more useful than they currently are displaying. As I previously stated, these Error dialogs are produced from run-time Evar evaluations. Evar evaluation has no context in the current code structure and therefor have no way to provide any more information than the variable that is being evaluated, and the reason why it failed evaluation (ie. Undefined, or Recursively defined). Part of the issue to note is that the Evar evaluation may not even be a result of invalid syntax on a line in the step.rc, but rather a module requesting an Evar that does not exist. What needs to happen is for the error dialogs to go away all together, and a mechanism provided to the interfacing code module to inform it that the requested evaluation was invalid, and then let the interfacing code module deal with the problem, rather than having the evaluation code itself throw the error dialog. At this time however we are not going to make that change. Another side affect of this issue to note is that duplicate error dialogs may be produced for an evaluation that has multiple errors.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
15	[litestep core] core	feature	N/A	2006-05-04 15:48	2007-01-22 19:18
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none
Summary:	Internal timer support
Description:	Timer.dll steals focus when interacting with LS modules and there is no way to restore it. A generic fix that would be handy would to either have : - internal timers controlled by LS - focus history (something like !restorefocus to set the focus back to the last focussed window)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000026) jugg    2006-05-06 20:53	As far as I can see, timer.dll does nothing to change the current active window. Perhaps it is the command that you have configured to be executed that is resulting in the focus being changed. In any case, I do not see how adding this functionality to the core would change matters. There is nothing (that I can think of) which the core has access to that a module does not in regards to the functionality of this module. As far as the focus history goes, again there is nothing special internal to the core that would allow this to be accomplished in a way that a module could not do. If there is any further information you want to clarify here please do, otherwise I'll probably go ahead and mark this invalid/won't fix (or maybe just move it over to the 'litestep modules' project).
(0000040) phil    2006-11-11 14:20	OK

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4	[litestep core] core	tweak	always	2006-04-26 15:12	2006-04-26 15:34
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none
Summary:	integer() does not round up values
Description:	integer(2.5) reports 2 as the value. Arguably, this should be 3. *shrug* This relates to bug 0000003 and may be a compatibility issue with 0.24.7
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000011) jugg    2006-04-26 15:34	Integer math truncates, it does not round so this is expected. Use floor() or ceil() or round(). Marking bug as invalid.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2	[litestep core] core	major	always	2006-04-19 13:26	2006-04-26 14:58
Reporter:	phil	Platform:
Assigned To:		OS:
Priority:	none	OS Version:
Status:	closed	Product Version:	CVS-024x
Product Build:		Resolution:	won't fix
Projection:	minor fix
ETA:	< 1 week
Summary:	EVars with numeric prefix are unusable
Description:	Variables starting with a numeral will cause the expression parser to fail.
Steps To Reproduce:	Blank step.rc, with just : 99Var "1" If 99Var EndIf will cause an error at startup : Error in Expression: 99Var Description: Syntax Error: Expected END, but found ID Note also the same issue is reported if you omit the conditional and simply do : !alert $99Var$
Additional Information:	This needs to be fixed to retain step.rc compatibility with 0.24.7.
Attached Files:	example.rc (0 KB) 2006-04-20 14:53

Notes
(0000005) jugg    2006-04-26 00:27	Apparently this may not be a valid bug. 00Var "1" IF 00Var Endif will evaluate to false in 0.24.7. The expression "00Var" is evaluated as a number, not a variable in both 0.24.7 and 0.24.8. The behavior is identical to 0.24.8, except that 0.24.8 (correctly) displays an invalid syntax dialog, whereas 0.24.7 (incorrectly) ignores the syntax error. Therefore 0.24.8 will not change from the current experimental build behavior in this regards, since the reported functionality is bogus. Please confirm or rebute this finding.
(0000006) phil    2006-04-26 10:35	LS 0.24.7 should only attempt to evaluate when faced with something like : If $(VARIABLE*2)+6$ ... EndIf or If ResolutionX > 1024 ... EndIf It should otherwise treat the string as the name of a variable. Meh. I'll change our code, something that has been in place for a good few years and has been working, but I still feel that this implementation in LS is broken.
(0000007) jugg    2006-04-26 13:57    (edited on: 2006-04-26 13:58)	Are you saying this is a bug between 0.24.6 to 0.24.7? In my previous note, I showed that 0.24.7 does not work as you are saying it 'should'. I need this clarified. I'm more than happy to fix this, if I can be shown that something is broken. At this point I see no functional change between 0.24.7 and 0.24.8 (ie. CVS-24x). Please explain further. Also just fyi, $ is not allowed in an IF expression, so your first example is invalid.
(0000008) jugg    2006-04-26 14:58	Further offline discussion shows that this bug is invalid. 0.24.7 did not allow variables starting with a numeric either. It quietly ignored them.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
56	[litestep modules] acidmail.dll	block	always	2008-06-16 07:52	2009-01-20 02:18
Reporter:	Acidfire	Platform:
Assigned To:	Acidfire	OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:	0.7-beta	Resolution:	open
Projection:	none
ETA:	none
Summary:	Regression in server connection
Description:	Certain servers will always report a connection error as soon as a command is sent. This is due to an command being sent right after a connection is made. Most servers will still accept this, some don't.
Steps To Reproduce:	studentweb.student.tue.nl reports error as soon as the "user" command is sent.
Additional Information:	Apparently the regression happened while switching from winsock 1 to winsock 2. Though it did still work in the earliest winsock 2 builds. I don't have the sources of those builds anymore though. The earliest released 0.7 beta already has the problem.
Attached Files:	acidmail_07b_06.pcap (2 KB) 2008-06-16 07:57 acidmail_07b2.pcap (1 KB) 2008-06-16 07:58

Notes
(0000126) Acidfire    2008-06-16 07:54	v0.6, 0.7b1 and 0.7b2 all show different TCP correspondence in WireShark.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
44	[litestep modules] acidmail.dll	block	random	2008-04-22 17:03	2008-06-16 07:41
Reporter:	Acidfire	Platform:	Windows
Assigned To:	Acidfire	OS:	XP Professional
Priority:	none	OS Version:	SP2
Status:	resolved	Product Version:
Product Build:	0.7-pre	Resolution:	fixed
Projection:	none
ETA:	none
Summary:	Randomly gets stuck at 100% usage
Description:	Only in this build, AcidMail causes a 100% cpu usage at random times. It hasn't happened while running the debug build (yet) so the code hasn't been broken into.
Steps To Reproduce:	Wait till it happens
Additional Information:
System Description	Windows EP Professional Service Pack 2
Attached Files:

Notes
(0000103) Acidfire    2008-05-13 18:43	Bug hasn't happened in latest builds. I have released a beta of the next version so stability can be tested. If the bug doesn't happen this issue will be closed.
(0000125) Acidfire    2008-06-16 07:41	Bug found and solved. AcidMail got stuck in a while loop when trying to shutdown a connection gracefully and a connection error happened at the same time.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
7	[litestep sdk]	major	always	2006-04-29 05:07	2009-02-28 12:53
Reporter:	ilmcuts	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Summary:	A few functions are missing from docs
Description:	There are a couple of functions which are already listed in index.html but which have no documentation page. Then there are some which aren't even mentioned in index.html.
Steps To Reproduce:
Additional Information:	Already listed but without docs page: Frame3D TransparentBltLS SetDesktopArea CommandParse GetResStr GetResStrEx is_valid_pattern match matche Not listed at all: LSGetSystemMetrics LSMonitorFromWindow LSMonitorFromRect LSMonitorFromPoint LSGetMonitorInfo LSEnumDisplayMonitors LSEnumDisplayDevices LSLog LSLogPrintf Some of these may be deprecated, but I doubt that all are.
Attached Files:

Notes
(0000164) jugg    2009-01-07 02:39	I've added documentation for: BitmapFromIcon CommandParse Frame3D SetDesktopArea TransparentBltLS
(0000196) jugg    2009-01-24 19:14	I've added documentation for: is_valid_pattern match matche
(0000197) jugg    2009-01-24 19:19	As a comment on a functions deprecated status... I think that all functions should be fully documented. In the future, we should also add a "compatible/available with litestep version x.x.x" note on each function, and any function that has been deprecated, should be clearly marked as such. But, like I said, all functions should be documented.
(0000231) jugg    2009-02-23 21:06	All functions have been documented.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
6	[litestep sdk]	major	N/A	2006-04-29 04:51	2009-02-28 12:52
Reporter:	ilmcuts	Platform:
Assigned To:	ilmcuts	OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	LM_xxx messages are not documented
Description:	Some of the LM_ messages from lsapidefines.h can and should be used or responded to by modules. Examples are LM_REGISTERMESSAGE and LM_REFRESH. These are currently not included in the SDK docs.
Steps To Reproduce:
Additional Information:	As the bare minimum these should be covered: LM_SAVEDATA / LM_RESTOREDATA LM_SYSTRAYREADY / LM_SYSTRAY LM_REGISTERMESSAGE / LM_UNREGISTERMESSAGE LM_GETREVID LM_REFRESH The HSHELL_xxx equivalents
Attached Files:

Notes
(0000012) ilmcuts    2006-04-30 14:24	Most of these are done. Only the hook messages and LSNOTIFYICONDATA (for LM_SYSTRAY) are missing. Should these be put into the lsapi directory where the function XML files currently are (filenames are LM_REFRESH.xml for example)? Should they also be listed in index.html alongside the "regular" functions? The title of the page currently says "Litestep *Functions* by Category".
(0000060) ilmcuts    2007-07-11 18:48	Well I've finally committed docs for most of the messages mentioned above. Known issues: a) hook messages are still missing b) as are LM_RELOADMODULE, LM_UNLOADMODULE, and LM_RECYCLE though they're not as important as LM_REFRESH for example c) LSNOTIFYICONDATA is absent
(0000076) ilmcuts    2007-12-23 17:36	LM_REGISTERMESSAGE should clarify that you can register for (almost) all window messages that run through the core's main wndproc.
(0000161) ilmcuts    2009-01-03 10:20	LM_RELOADMODULE, LM_UNLOADMODULE, and LM_SHELLHOOK are done. However, they all should be reviewed. This leaves LSNOTIFYICONDATA.
(0000230) jugg    2009-02-23 17:42	We are still missing LM_RECYCLE and LM_BANGCOMMAND, both are module->core messages.
(0000244) ilmcuts    2009-02-28 05:49	LM_BANGCOMMAND is an internal message, IMO. I'm pretty sure a couple of older modules use LM_RECYCLE, but is there any good reason for modules to use it nowadays? I think we should document it but mark it as deprecated.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
91	[litestep sdk]	block	N/A	2009-02-28 12:51	2009-02-28 12:52
Reporter:	jugg	Platform:
Assigned To:	jugg	OS:
Priority:	none	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	LiteStep 0.24.8 SDK - Release
Description:	This is a parent issue for all the issues that need to be fixed for the 0.24.8 SDK.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.