This fixes a race condition where the directory is deleted before the
window closes, which causes an error dialog to appear.
Cutting the number of iterations per wait loop in half is necessary so
that doubling the number of wait loops does not result in a timeout when
new tests are added.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some Windows 8.1 and Windows 10 1507 versions return PATH_NOT_FOUND
instead of FILE_NOT_FOUND.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When there is more than one CD drive the extra drives typically get a
folder called "Burn1", etc.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Doing so fails process creation for relative current directory as the
directory already made current.
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The shellview menu IDs are very large, eg. FCIDM_SHVIEW_OPEN is 0x7102,
while applications want menu IDs to fit into a small range, eg. 1-1000 for
Explorer++. This causes our IContextMenu_QueryContextMenu() functions to
leave out most menu options. We should rebase our shellview menu ids
by -0x7000 so they occupy a smaller range.
This gets both Explorer++ and Double Commander to show the correct
right-click menus.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=24893
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Show Shell_MergeMenus() really adds the offset instead of
changing IDs to start with it, and that it really honours
the maximum allowed value.
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes crash on start in Worms World Party Remastered.
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Since the test no longer uses a random directory name, the directory is
more likely to exist already. So use it even if it already exists.
Also on some Windows versions (e.g. Windos 2008) GetLongPathName() does
not return the long name if the path does not exist. So do the
conversion before appending the new directory name.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Several older Microsoft installers, particularly those changing CDs
during installation, break because they launch a child setup.exe, from
a parent process also called setup.exe, which Wine finds in the wrong
directory, as CreateProcess() first searches the parent executable's
own directory, thus re-launching the parent itself instead of the
child. Therefore CreateProcess() must be passed a full path from
SHELL_execute(), so it launches the correct child.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=8439
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In case of a failure it is necessary to show the path that was passed
to ShellExecute(). That means the paths must not be randomized so as
not to prevent the TestBot from detecting new failures.
Note that because of the registry modifications one cannot run two
instances of the test concurrently anyway.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Report the line number where the test failed to wait for the child so
one can identify which child process did not behave as expected.
Also wait_child_process() is meant for the general case so report
all non-crash error cases as test failures so they are accounted for.
Omit the "winetest_" prefix to match the other Wine test functions and
so the underlying winetest_wait_child_process() function can be wrapped
with the usual line-capturing macros.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48651
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>