Noticed when using the most recent version of grepWin, when I triggered a start using a pinned taskbar shortcut, grepWin would always present the Windows system directory as the default search path. Previous versions would default to the last search path used (stored in the registry). Noticed that changes were made in the recent implementation to fallback on the working directory (maybe to support invoking grepWin from command line?). Figured this hack may be preferred to deal with start-menu/pinned starts; however, I'm not sure if I am overlooking any other use cases.
Change note
Changes have been introduced into grepWin where the current working directory is used as fallback search path to use when no path is provided from the command line/context-menu invoke. A possible undesired effect from this change is that when grepWin is invoked from a taskbar pin or the start-menu, the default working directory will be the Windows system path. Users starting grepWin without a possible target directory are no longer presented with the last saved search folder.
This commit attempts to allow users to still fallback to the last searched folder by ignoring the case where the system directory is detected as the current working directory.
An undesired effect of this change is that if a user was in the system path and invoked grepWin without a path argument, they would not be presented an instance where the search path matched their working directory (note: context-menu invokes still work as expected). While this may be undesired, it is assumed that the probability of that use case is significantly smaller than a user invoking grepWin from a pinned taskbar.
Prelude
Noticed when using the most recent version of grepWin, when I triggered a start using a pinned taskbar shortcut, grepWin would always present the Windows system directory as the default search path. Previous versions would default to the last search path used (stored in the registry). Noticed that changes were made in the recent implementation to fallback on the working directory (maybe to support invoking grepWin from command line?). Figured this hack may be preferred to deal with start-menu/pinned starts; however, I'm not sure if I am overlooking any other use cases.
Change note
Changes have been introduced into grepWin where the current working directory is used as fallback search path to use when no path is provided from the command line/context-menu invoke. A possible undesired effect from this change is that when grepWin is invoked from a taskbar pin or the start-menu, the default working directory will be the Windows system path. Users starting grepWin without a possible target directory are no longer presented with the last saved search folder.
This commit attempts to allow users to still fallback to the last searched folder by ignoring the case where the system directory is detected as the current working directory.
An undesired effect of this change is that if a user was in the system path and invoked grepWin without a path argument, they would not be presented an instance where the search path matched their working directory (note: context-menu invokes still work as expected). While this may be undesired, it is assumed that the probability of that use case is significantly smaller than a user invoking grepWin from a pinned taskbar.