Can someone show me how to use "IShellExecuteHook.Execute" in Delphi please?
info: IShellExecuteHook::Execute Method
Description:
This method is called any time the ShellExecute or ShellExecuteEx functions are
called. This happens when a file is double-clicked in Explorer or when the Run dialog
box is used.
Thanks.
The following EDN link looks like it will give you what you need: How to hook ShellExecute calls (IShellExecuteHook)
Be aware that it won't work in 64 bit Windows because that requires 64 bit shell extensions and because Delphi only produces 32 bit images you would need to use a different language. I also note that IShellExecuteHook is deprecated as of Vista.
Related
I have a few things like running SFC, defrag, and reset the page file and so on, things that can be done within windows VBScript, I am just wondering if I can compile that code as a resource and call it as needed. Thanks.
Lee
You can use the Windows Script Host interfaces, IActiveScript and IActiveScriptParse, to execute Javascript/VBScript from memory. You can then compile your Javascript/VBScript into a resource, extract it at runtime, and then execute it when needed.
Update: have a look at this blog article:
Adding Active Scripting to your
Delphi Win32 application
And then look at this discussion to make it work in 64bit:
Writing a scripting host in Delphi XE2 64-bit
I have set up the QODBC driver and was able to connect to my QB file and run queries in the VB Demo 32.
I am looking at one of the Sample Files, found here - http://support.flexquarters.com/esupport/index.php?/Default/Knowledgebase/Article/View/506/57/examples-of-how-to-use-qodbc-via-visual-basic
I did what this article said - copied all of the text into a text file, saved it as "Customer.vbs". I created a Customer named "Kim Garland", closed the dialogue box, double clicked on the file. The msgbox never displayed, and this error message came up - "[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application; Code: 80004005; Source: Microsoft OLE DB Provider for ODBC Drivers"
Any idea what is going on here? After looking through the knowledge base, I thought it might have something to do with 64-bit vs 32-bit... but that didn't seem to get me anywhere. I do have Visual Studio installed, but don't quite know enough about VB6 apps to know what I'm doing.
EDIT
By the way, the line that is giving the error is:
oConnection.Open "DSN=Ben Test 2;OLE DB Services=-2"
I originally was using the same exact line that was in the article that I linked to, but that was not working either. I used the c:\windows\syswow64\odbcad32.exe to create a 32-bit DSN called "Ben Test 2". It didn't seem to change anything.
Please take a look at the Microsoft's website where they talk about it.
It is not VB issue, it is 32/64bit issue as you suspect.
http://social.msdn.microsoft.com/Forums/en/sqlgetstarted/thread/702f0d9b-6cb9-49cf-9953-80d059711e60
Since you are using 64-bit system, your VBS will be execute as 64-bit (by default).
QODBC is 32-bit driver, and can work with 32-bit applications. A 64-bit applications cannot talk to a 32 bit Driver and same is with 64bit application to 32 bit Driver.
For 64-bit applications use QRemote (which is a 64-bit Driver driver).
Solution 1
You can try to use QRemote to bridge QODBC and your application. Here is an article about how to use QRemote:
http://www.qodbc.com/qremoteconnect.htm
Solution 2
and there is another solution for you issue. Please call your VBS as 32 bit. Please follow the steps below:
1) Click Windows Start
2) Click Run, in the window, type "%windir%\SysWoW64\cmd.exe"
3) Click OK, then type "cscript vbscriptfile.vbs" in the cmd window
This will make your VBS run in 32-bit mode even thou you are in 64-bit machine
-Regards
Rajendra Dewani
I have some files that use alternate data stream and are not shown on windows explorer. I would like to make a shell extension or a program that runs on background that when I use windows explorer and navigates to a folders that has alternate data streams files, to show this file to windows explorer but with an overlay icon on it.
Is this possible? Is there a sample code to check?
Thanks a lot.
Another, more recent, option, that works with Windows Explorer x64, too, is AlternateStreamExtension. It also provides icon overlays.
You can find it here.
There's already a shell property sheet handler available from Microsoft called StrmExt. Granted, it's not quite what you're looking for, was written for Windows 2000 and Windows XP, and has to be recompiled for 64 bit versions of Explorer, but it includes the C++ source code, which should give you a place to start, at least.
In Windows Vista, two new API functions were introduced to allow easier enumeration of Alternate Data Streams: FindFirstStreamW and FindNextStreamW. These functions work much like the other FindFirstX and FindNextX type functions that have been in Win32 for years.
I made shell extension (implementing IContextMenu, IShellExtInit, IExtractIcon & IPersistFile) using ATL, "by the book".
The funny thing is that all is good in some files-managers such as "Total Commander" & "Free Commander", but completely fail in Windows' Explorer:
When I right click on my registered file (say *.000) in TC ("Total Commander"), the extension works: I see it in my logs and in the context menu: the entry with its icon appear.
But if I use Win-Explorer, nothing happens! no log entry comes up, no evidence in the context menu - nothing! even a complete PC restart doesn't help.
I of course registered the ShellEx\MyX\ContextMenuHandlers and ShellEx\IconHandlerkeys, as well as the Explorer's ...\Shell Extensions\Approved\, and they all point to my CLSID.
I use Windows 7.
What do I miss here ?
#SevaTitov answered my question but as a comment, so for future references for anyone who stumbles upon this issue:
#SevaTitov:
If your OS is 64 bit, the Explorer will be 64 bit as well, and all your shell extensions will have to be 64 bit as well. Looks like current version of Total Commander is 32 bit only
There's that thing, Registry Redirector, that when you're in 32-bit program, it hides ("redirects") the 64-bit reg-entries, and vice versa.
I was confused because in my 32-bit registry-viewer-app I could see those keys, but was unaware that I only see a part of the registry (the 64-bit part has to be seen with a 64-bit viewer like the default regedit.exe in a 64-bit Windows machine)
I have some customers/candidate who complained that my program doesn't work on their Windows 7 64 bit version (confirmed with screenshots). The errors were strange, for example:
in the trial version i am
getting a error message whenever i
click on \"mark\" \"delete\" \"help\".
error msg is: Access violation at
address 0046C978 in module
\'ideduper.exe.\' read of address
00000004
windows 7 ultimate 64bit. i7 920
#2.67GHz 9gb or ram
'Mark', 'delete' and 'help' are just standard TToolButton on TToolbar.
The other example is failing to get a thumbnail from IExtractImage.
I have told them to try Compatibility mode but still doesn't work.
The problem is when I tested it on Windows 7 HP 64-bit on my computer (which I've done it before released it actually) it just works fine! So I don't know what causing it
Do you have any advice ?Are different Windows package (home basic,premium,ultimate,etc) treating 32 bit prog differently ?Are the newer version of Delphis (I use 2006) more compatible with 64 bit Windows ? Do I need to wait until 64 bit compiler out?
Thanks in advance
Your best bet in my opinion is to add MadExcept or EurekaLog or something similar to your application and give it to the customer to try again. MadExcept will generate log with stack trace, which will give you a clearer view of what is happening there.
To answer 2nd part of the question, 32bit Delphi programs work fine on 64bit Windows 7. I think it's more likely you have some memory management problems and the customer just happens to stumble upon them while you don't. Use FastMM4 to track those down.
Your applications is trying to access an invalid pointer. Changing environment may surface issues that are hidden in others. Check your application, and use FastMM + JCL+JCVL/MadExcept/EurekaLog to get a detailed trace of the issue. Some Windows APIs may have some stricter call requisites under 7 and/or 64 bit, but we would have to know what your app actually cals.
A free alternative to MadExcept is JCL Debug stuff. However it is less thorough and doesn't include the cool dialog box to send the stack trace to you via email, or as a file you can attach and manually email.
MadExcept is worth the money, and it is free for non-commercial use. You could try it first on your own PC, observe its functionality, and be sure it functions the way you want, and then buy it.
If buying Delphi is worth it (and it is!) then buying mad Except is a no brainer. But if you insist on rolling your own, JCLDebug (part of jedi code library) is also pretty nice.
Give them a stripped down version of your app and see when the problem goes away. I am betting it is your code as I never had any problems with my (hundreds of) W7/64 clients.
I'd be willing to bet it's an issue in your code. The reason it's failing on your customer's machine and not yours is that your machine probably has the default Data Execution Protection (DEP) enabled (which is turned on only for essential Windows programs and services), while your customer's computer is actually using DEP as intended (turned on for all programs and services).
The default setting (which is compatible with older versions of Windows, like 95/98/ME), allows software to execute code from what should be data segments. The more strict setting won't allow this, and raises a system-level exception instead.
You can check the settings between the two by looking at System Properties. I'm not at a Win7 machine right now, but on WinXP you get there by right-clicking on My Computer, choosing Properties, clicking on Performance Options, and then selecting the "Data Execution Prevention" tab. Find it on Vista/Win7 by using the Help; search for Data Execution Protection.
The solution, as previous answers have told you, is to install MadExcept or EurekaLog. You can also get a free version as part of JEDI, in JCLDebug IIRC. I haven't used it, so I can't vouch for it personally. I've heard it's pretty good, though.
If you don't want to go that route, set a breakpoint somewhere in the startup portion of your app (make sure to build with debugging info turned on). Run your app until the breakpoint is hit, and then use the IDE's Search->Goto Address (which is disabled until the breakpoint is hit). Enter the address from the exception dialog (not the one that's almost all zeros, but the 0046C978 address, prefixed with $ to indicate it's in hex) as in $0046C978. You'll probably end up in the CPU window looking at assembly code, but you can usually pick out a line of Delphi code of some sort that can sometimes give you a place to start looking.
In addition to all previous suggestions, I'll add the difference in accessing Registry under WOW64 compared to Win32. If your application is accessing Registry to read or write some settings, you should be aware of this. First, take a look at this and this page in the MSDN. On this page you will find 2 flags that determine the access you get to Registry from 32- or 64-bit application. KEY_WOW64_64KEY is the one that you should use.
In any case, I agree with others about using madExcept (or any other similar tool) to be able to find the exact cause of your problems.