i seem to be having some odd troubles with ShellExecute such that i am trying to execute a link as such:



; szOpen = "open"
invoke ShellExecute, hwnd, addr szOpen, addr szMyLink, 0, 0, 0


the problem is that if i close the window shortly after it is opened the whole system practically halts for about 10 seconds, then is back to normal....

this doesn't happen if i leave it open for a bit

also, it seems to halt the system if i try and execute this multiple times ( i.e: shellExecute is called on button click; if i click the button alot )

also odd is that it always returns "42" which, according to the API, is fine:

If the function fails, the return value is an error value that is less than or equal to 32.


... so does anyone know what the problem is?
Posted on 2003-04-20 02:35:02 by abc123
Hi,

szOpen and szMyLink should be null terminated:

szOpen DB "open",0
szMyLink DB "whatever",0

Regards,

akyprian
Posted on 2003-04-20 02:55:17 by akyprian
returning "42" is very good. As far as I remember its the answer to everything.
Posted on 2003-04-20 03:03:59 by japheth
abc123,

You can either use CreateProcess() or WinExec() if you don't need the extra parameters. WinExec() maps directly to CreateProces anyway so it no problem to use and you should not suffer the time lag with it.


invoke WinExec,ADDR Name_Of_File,SW_SHOW

Name_Of_File is a normal zero terminated string that contains the path and filename.

Regards,

hutch@movsd.com
Posted on 2003-04-20 03:24:25 by hutch--
hutch,

tried winExec and it did nothing.. perhaps because "file" is "http://127.0.0.1" ...


akyprian,
yup, they are both 0-terminated.
Posted on 2003-04-20 03:27:56 by abc123
OK,

Your lag problem is related to the TCP/IP processing speed of your box or connection and local process functions will not work with them.

Sorry I cannot be of much use to you here.

Regards,

hutch@movsd.com
Posted on 2003-04-20 03:32:49 by hutch--
i see... at least i can blame the computer then, thank you :)
Posted on 2003-04-20 03:38:41 by abc123
Well, not quite, where you start a browser with ShellExecute(), you are doing something different to starting a process locally on your own machine.

You may improve the speed with direct Winsock calls if you have the need but if you are getting a lag calling a URL, it has something to do with how you machine processes TCP/IP.

The variables are many, processing speed, number of other TCP/IP processes running, connection speed if that matters so yes, you can blame the computer. You are free to set it up any way you like to improve this though. :tongue:

Regards,

hutch@movsd.com
Posted on 2003-04-20 04:08:07 by hutch--
hmm, this seems to be very annoying now...

what would be the ways i can eliminate this lag? is there an option to start iexplore with a url specified ?
Posted on 2003-04-20 04:45:14 by abc123

hmm, this seems to be very annoying now...

what would be the ways i can eliminate this lag? is there an option to start iexplore with a url specified ?


Can you show us the whole code?

I doubt its a "lag" problem, as the browser should start _before_ it tries to lookup the address.
Posted on 2003-04-20 05:13:16 by bazik
well the code is basically:

; szOpen db "open", 0

; szweb db "http://127.0.0.1", 0
.elseif umsg == WM_LBUTTONDBLCLK
mov eax, hwnd
.if eax == hSomeButton
invoke ShellExecute, hwnd, addr szOpen, addr szweb, 0, 0, 0
.endif
.endif



but i think it lag is the problem because i tested "running" the url by putting in run then closing it fast, lag occured for about 5-10 seconds......
Posted on 2003-04-20 05:18:18 by abc123
Do you check for WM_LBUTTONDBLCLK in your Window proc or the subclassed Button?
Posted on 2003-04-20 05:33:05 by bazik
... only in the button wnd proc ( which is where that code is from ), did you want to see *all* the code ?
Posted on 2003-04-20 05:39:37 by abc123

... only in the button wnd proc ( which is where that code is from ), did you want to see *all* the code ?


Nope.

But if its in the subclassed Button WndProc, you dont need the check for the handle as this message is only send on double-click inside the button.
Posted on 2003-04-20 05:46:04 by bazik
i use this proc for many buttons :)
Posted on 2003-04-20 05:48:42 by abc123
This works for me:





.DATA

shell_file db "http://board.win32asmcommunity.net",0

.CODE

.elseif ax==902
invoke ShellExecute, hDlg, NULL, ADDR shell_file, NULL, NULL, SW_SHOWNORMAL
mov eax, TRUE
ret
.



xyzero
Posted on 2003-04-20 13:42:43 by xyzero
for those who are interested this problem isn't experienced on win2k ( prob is on XP tho )
Posted on 2003-04-24 03:37:29 by abc123
WinExec / CreateProcess != replacement for ShellExecute. ShellExecute does a lot of special handling involving registry access etc - that's why you can ShellExecute a .doc file - doubt WinExec/CreateProcess lets you ;).

Too bad ShellExecute is rather limited... you don't get any process handle etc. Iirc ShellExecute is async, which makes it hard to wait for child process termination. ShellExecuteEx should give you a hinstance, though, and works on 95+ and NT4+.

Sorry that this didn't help anything with your problem. Humm, I can't remember if ShellExecute blocks your thread until the process is started (and possible initialized, as per WaitForInputIdle), or if it returns right after the CreateProcess call. If it's the former, that would explain lag on some operations.
Posted on 2003-04-24 04:38:33 by f0dder
f0dder:
doesn't seem to halt the thread, so i think its just a bug on xp :(

hutch:
now i don't think its a winsock lookup prog as i am testing with my local webserver only so no big lookup required....


it could just be a bug of my computer, it has started experiencing some odd bugs ever since i started in assembly..

i wonder if that is just co-incidence.... :D
Posted on 2003-04-24 07:03:06 by abc123

doesn't seem to halt the thread, so i think its just a bug on xp

ok, makes perfect sense - shellexec is async. Dunno if it's a XP bug though, but further investigation should show.


it could just be a bug of my computer, it has started experiencing some odd bugs ever since i started in assembly..

i wonder if that is just co-incidence.... :D

A coincidence. The errors you'd make in asm would usually end up in GPFs :). That, and a few weird things because of:

*) struct, and struct member, alignment
*) stack alignment
*) alignment in general of "some stuff"
*) failure to preserve registers
*) failure to initialize variables / structures
Posted on 2003-04-24 07:06:52 by f0dder