W
Willy
This thing is complicated so bare with me.
We have a pure .NET application using an SQL express database which we
deploy via ClickOnce. When we launch the application via the normal
shorcuts (internet or program files) it *always* works.
Now the beauty is that this application has to be launched from a ***16 bit
Delphi 1 application*** (nobody chooses this, neither did we - the 16bit app
will live for at least 2 years - and this application is still used by tens
of thousands of customers). This delphi application has a plugin mechanisms
which enabled us to load 16-bit "add-ins". The short shory is the 16 bit
application uses WinExec (exePath,SW_NORMAL) to launch our app. (we have
control over the parameters but not over the WinExec part - the first
parameter should be an EXE as well)
Since the 16-bit app can't call an appref-ms (we launch the appref-ms file
in program files\ourCompany\ourproduct as created by ClickOnce and
documented in http://safari.oreilly.com/0321197690 ) file directly and since
the clickonce application doesn't take program parameters, we have created
a man in the middle .NET application (MyBoot.EXE) to do the work for us. It
takes the commandline parameters from the delphi app and puts them in a
local file for the .NET ClickOnce app.
Now listen :
- on windows vista it always works
- on windows XP it sometimes works (but most of the time it does not)
- if I manually launch myBoot.EXE with the commandline parameters then it
always works.
The question :
- is there something different with Windows on Windows for 16 bit
applications between XP and Vista or is my Vista machine just faster than
all of the XP machines (3) on which I tested this ?
- how can I overcome this problem ?
(already tried increasing the timeout for the connection string but it
doesn't have anything to do with that - is it the switch between 16bit code
and 32 bit code? - I've also tried launching the .application file but that
doesn't help me either - I've also made the man in the middle a windows
application with an application.Doevents to take care of the warnings for
WinExec)
Thanks for any help,
Van den Driessche Willy.
(sorry for the cross-posts)
We have a pure .NET application using an SQL express database which we
deploy via ClickOnce. When we launch the application via the normal
shorcuts (internet or program files) it *always* works.
Now the beauty is that this application has to be launched from a ***16 bit
Delphi 1 application*** (nobody chooses this, neither did we - the 16bit app
will live for at least 2 years - and this application is still used by tens
of thousands of customers). This delphi application has a plugin mechanisms
which enabled us to load 16-bit "add-ins". The short shory is the 16 bit
application uses WinExec (exePath,SW_NORMAL) to launch our app. (we have
control over the parameters but not over the WinExec part - the first
parameter should be an EXE as well)
Since the 16-bit app can't call an appref-ms (we launch the appref-ms file
in program files\ourCompany\ourproduct as created by ClickOnce and
documented in http://safari.oreilly.com/0321197690 ) file directly and since
the clickonce application doesn't take program parameters, we have created
a man in the middle .NET application (MyBoot.EXE) to do the work for us. It
takes the commandline parameters from the delphi app and puts them in a
local file for the .NET ClickOnce app.
Now listen :
- on windows vista it always works
- on windows XP it sometimes works (but most of the time it does not)
- if I manually launch myBoot.EXE with the commandline parameters then it
always works.
The question :
- is there something different with Windows on Windows for 16 bit
applications between XP and Vista or is my Vista machine just faster than
all of the XP machines (3) on which I tested this ?
- how can I overcome this problem ?
(already tried increasing the timeout for the connection string but it
doesn't have anything to do with that - is it the switch between 16bit code
and 32 bit code? - I've also tried launching the .application file but that
doesn't help me either - I've also made the man in the middle a windows
application with an application.Doevents to take care of the warnings for
WinExec)
Thanks for any help,
Van den Driessche Willy.
(sorry for the cross-posts)