DDE in Windows 7 vs Windows XP
Petrica7
Hi.
Sorry for my english...
I'm a programmer (Delphi).
Recently I've modified one of my programs to work with DDE. To be more
specific when the user selects one or more files in Explorer and click on
"Add" command from the context menu the application is started and the files
(names) are loaded in a list. So the filenames are sent using a comunication
client >> server.
In Windows XP I can select even 1000 files - it works well.
In Windows 7 if the user selects 2 or more it's not working well. It loads
only the first file. For the rest it shows a standard error message saying
that there isn't an application associated with the file.
Oh, the problem appear only when the application need to be started, not
when it's already started.
I presume that DDE work differently in Windows 7 but I couldn't find any
documentation about that.
Does anybody has an ideea why is doing that..? And maybe even a solving to
the problem.. ?
Thank you in advance.
C. Kevin Provance
news:C33F2BB7-D49E-410F...@microsoft.com...
You are aware this is a VB newsgroup? Try asking in a delphi NG.
Petrica7
Plus my question isn't 100% about Delphi programming.
It's more about the difference between DDE from Windows 7 and the one from
Windows XP.
But ok, I'm sorry, I'll ask elsewhere...
Ralph
The error is suggesting an "association problem", so check out this article
and dynamic dde????
http://msdn.microsoft.com/en-us/library/cc144171(VS.85).aspx
And I see what you mean about problems with Win7, appears to be a lot of
questions but not a lot of answers - many of the 'solutions' seem to point
to conflicts with other loaded applications using DDEML. So you might insure
only your application is running to test.
I haven't had to test any DDE applications on Win7 - yet. Definitely not
looking forward to it. If you find the cause and it isn't Delphi specific -
please report back.
-ralph
MikeD
"Ralph" <nt_cons...@yahoo.com> wrote in message
news:O8YY5Oef...@TK2MSFTNGP02.phx.gbl...
I'm actually kind of amazed DDE is still supported in any form in Windows 7.
Seems to me that that's a technology that just needs to be allowed to
die....finally.
--
Mike
Petrica7
The program it's doing the associations (in Windows registry) like this:
HKEY_CLASSES_ROOT (if it can't write there tries in
HKEY_CURRENT_USER\Software\Classes)
MyProgram.1
(Default) = "MyProgram Application"
Shell
(Default) = "open"
add
command
(Default) = "C:\MyDir\MyProgram.exe"
ddeexec
(Default) = "/AddFile %L"
application
(Default) = "MyProgram"
topic
(Default) = "System"
open
command
(Default) = "C:\MyDir\MyProgram.exe"
ddeexec
(Default) = "/OpenFile %L"
application
(Default) = "MyProgram"
topic
(Default) = "System"
Like I said, in Windows XP all is fine.
In Windows 7 it doesn't seem to be a conflict with other loaded applications
using DDEML.
I know that DDE is old but I'm trying to make a program that can work well
in any Windows version starting with Windows 98. Yes, Windows 98, because
I've seen computers still using it...
Thorsten Albers
<eEnDCSff...@TK2MSFTNGP06.phx.gbl>...
> I'm actually kind of amazed DDE is still supported in any form in Windows
7.
> Seems to me that that's a technology that just needs to be allowed to
> die....finally.
While or shortly after Win XP had been released MS told us that DDE support
will be removed from future versions of Windows. If DDE made its way
through to Win 7 (and still is used extensively even by 'modern' MS
applications), it somehow must be very, very usefull...
--
Thorsten Albers
albers (a) uni-freiburg.de
C. Kevin Provance
| Thank you.
|
| The program it's doing the associations (in Windows registry) like this:
|
| HKEY_CLASSES_ROOT (if it can't write there tries in
| HKEY_CURRENT_USER\Software\Classes)
<snip>
| Like I said, in Windows XP all is fine.
| In Windows 7 it doesn't seem to be a conflict with other loaded
applications
| using DDEML.
|
| I know that DDE is old but I'm trying to make a program that can work well
| in any Windows version starting with Windows 98. Yes, Windows 98, because
| I've seen computers still using it...
Are you sure your not experiencing a permissions issue here? Under Vista
and 7, writing to either of those keys (and in reality HKCR and
HKEY_CURRENT_USER\Software\Classes are the same thing) requires admin
elevation. It was never an issue under XP or lower because the OS did not
enforce it.
Petrica7
I checked and all these keys/values are wrote there.
I even tried to deactivate User Account Control. No change.
By the way, writing in HKEY_CURRENT_USER\Software\Classes doesn't require
admin elevation (at least in Delphi...). You can write even if User Account
Control is active.
"C. Kevin Provance" wrote:
> .
>
Ralph
Did a quick test on Win7 with a VB6 app and one VC++ utility that are doing
pretty much the same thing. No problems. No Errors.
It has to be something more subtle than the fact the app is running on Win7.
-ralph
Petrica7
I mean select multiple files, give the command from context menu, Windows
loads the server and send him the filenames using multiple DDE..?
Like I said, if I try with the server already loaded all is ok.
It's like, if I try on n files, one is sended and for n - 1 is not "patient"
enough to wait in the queue.
In XP is waiting...
"Ralph" wrote:
> .
>
Petrica7
My program at start rewrites every key/value from registry (from the ones I
mentioned). It deletes the entire "type" and writes again the keys/values. It
does that because I found programs that modifies keys/values (created by my
program for itself only) to work for other purposses.
Windows XP doesn't mind but I see that Windows 7 is "sensitive" about that.
The keys/values are written very fast (few ms I think) but it's enough.
Sorry guys and thank you very much for help.
C. Kevin Provance
| I'm sure it's not a permissions issue (with registry).
| I checked and all these keys/values are wrote there.
| I even tried to deactivate User Account Control. No change.
| By the way, writing in HKEY_CURRENT_USER\Software\Classes doesn't require
| admin elevation (at least in Delphi...). You can write even if User
Account
| Control is active.
Whoops, I misread.
Okay, first, to correct myself, coz I misread, the HKCR is nothing more than
a localized recreation of HKLM\Software\Classes (I see now you indicated
HKLM, which was my misread). Before you tell me I'm wrong, the info comes
directly from MSFT.
http://support.microsoft.com/kb/256986
The relevent portion:
"HKEY_CLASSES_ROOT is a subkey of HKEY_LOCAL_MACHINE\Software. The
information that is stored here makes sure that the correct program opens
when you open a file by using Windows Explorer. This key is sometimes
abbreviated as "HKCR." Starting with Windows 2000, this information is
stored under both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that can
apply to all users on the local computer. The
HKEY_CURRENT_USER\Software\Classes key contains settings that override the
default settings and apply only to the interactive user. The
HKEY_CLASSES_ROOT key provides a view of the registry that merges the
information from these two sources. HKEY_CLASSES_ROOT also provides this
merged view for programs that are designed for earlier versions of Windows.
To change the settings for the interactive user, changes must be made under
HKEY_CURRENT_USER\Software\Classes instead of under HKEY_CLASSES_ROOT. To
change the default settings, changes must be made under
HKEY_LOCAL_MACHINE\Software\Classes. If you write keys to a key under
HKEY_CLASSES_ROOT, the system stores the information under
HKEY_LOCAL_MACHINE\Software\Classes. If you write values to a key under
HKEY_CLASSES_ROOT, and the key already exists under
HKEY_CURRENT_USER\Software\Classes, the system will store the information
there instead of under HKEY_LOCAL_MACHINE\Software\Classes. "
Choice of programming language is not the issue. This is the reason your
app can't write to HKCR under Win7, because of elevation issues, but why you
*can* write to HKCU, because that's where MSFT want's folks to store their
setting, per user.
I don't know squat about DDE, so there isn't much else I can say about that.
I do however understand the complexities of how apps should work under
Vista/7 in terms of where stuff can be written to and not written to, what
works in terms of cross process communication and what doesn't, having done
months of research and testing for VB6 in an effort to make my apps
compatible and not need admin privs.
I do have an app (A VB AX EXE) that adds an entry to the Explorer context
menu for editing .manifest files in .exe files. Since I knew HKLM was going
to be a no go for Vista and higher, I used the HKCU solution and it worked
great. It overrode the HKLM settings, but it was only for that user. UAC
was on (since most of my ends users have it on by default) and it never
triggered once.
I don't know if any of this helps, but there you go. :-)
- Kev
Ralph
Glad you found it, and thanks for reporting back.
-ralph
Karl E. Peterson
Just about every application out there (flamebait <g>) uses it to
accept filenames from the OS. Can't break "just about every
application out there" right?
--
[.NET: It's About Trust!]
