I am attempting to get the QBSDK running on my Windows 7 machine. I am trying to run the sample program called EventHandler. It is run in conjunction with the sample EventSubscribe. I have compiled these in Visual Studio 2008. The EventHandler has a option in the File menu called Register Call Back Interface. When I run that it indicates that the COM connection has been created, however when I try to subscribe to an event in the EventSubscribe sample program it gives me the error “The callback application cannot be found from the CLSID or ProgID provided in the subscription request.”
On my Windows 7 machine after I did the Register the Callback Interface I noticed that the Unregister command was not highlighted. I also compiled this on a Windows XP machine with Visual Studio 2008 and I noticed the Unregister was highlighted. I do not have Quickbooks on the Windows XP machine though.
I have tried many things to get this to work… Any idea what is happening?
I am using C++
Thanks,
Jim
This may not directly describe your situation but the concept is similar. Starting with Vista, there were quite a few workarounds with QuickBooks SDK (and other COM-based technology) that required "Run As Administrator" to configure due to Windows UAC restrictions.
From the SDK documentation:
After you subscribe your menu extension events and
register them as documented, you need to run QB
using "Run As Administrator." This only has to be
done ONCE, after running QB as admin once, your
menu items will continue to show up and menu
events will be received by your event handler without
running QB as admin.
The general principle is that even if you are running Windows under an Administrative account, you may need to "Run As Administrator" both the QuickBooks UI, and your application that uses QBSDK, during the configuration process. Once all the registration and configuration is done it should work as a normal user.
Related
My C++ application uses ShellExecute to open a PDF file. I'm using Windows 10 Enterprise LTSC (version 1809, OS build 17763.615) to run my application. If my application is launched as Admin (right-click Run as administrator) then it fails to open the PDF file. However, if my application is launched without Admin rights (just double-clicking it) then Adobe (the default PDF reader) is launched successfully and the PDF is displayed correctly.
My application runs normally (with and without Run as admin) on Windows 7 and Windows 10 Pro. This issue just started happening now that we are trying to use Windows 10 Enterprise LTSC.
The actual code from my application is:
ShellExecute(NULL, NULL, full_path.toWideCharPointer(), NULL, NULL, SW_SHOWDEFAULT);
where full_path is for example equal to "C:\\Faxitron\\Docs\\Guide.pdf".
In both cases (admin or not), ShellExecute always returns 42 and GetLastError returns 0. Here is something interesting: when running my application as Admin, the Task Manager shows 2 processes of Adobe Acrobat Reader DC (32 bit) under my application, but the program Adobe is never launched/opened.
Not sure if this is relevant or not, but I'm using the latest version of Adobe Acrobat Reader DC (version 19.012.20034).
Finally, my application requires to be run as Admin (for other functionality to work properly). Is there a way to get ShellExecute to work when running application as administrator?
The reason why ShellExecute cannot launch the PDF viewer from an elevated process, in this case, is because Adobe Reader is preventing it via its Protected Mode. To solve this issue disable protected mode by doing the following:
Open Adobe Reader.
Choose Edit > Preferences...
In the Categories list on the left, select Security (Enhanced).
In the Sandbox Protections section, deselect Enable Protected Mode at startup
Click OK to save the changes.
Close Adobe Reader.
For more information about Protected Mode (and possible vulnerabilities) refer to this link from Adobe.com:
https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/protectedmode.html
I've developed an Accessibility API console application in C++ for High Sierra (and lower) - uses AXUIElementCopyAttributeValue etc.
I've disabled SIP to give me a chance here to write to the Accessibility database using tccutil.
So, the application runs as expected in Xcode, given that I've enabled 'Xcode' in System Preferences->Security & Privacy->Privacy->Accessibility.
I've wrapped my console application into a .app so I can drag and drop into this Accessibility panel.
If I run the application outside of Xcode in a Terminal window, I have to also give Terminal.app Accessibility rights for the application to use the API otherwise nothing is extracted. This then seems that you must give the calling application the rights.
I'm trying to launch the application on startup via a LaunchAgent with root privileges, /usr/bin/sudo being the calling application. Launching a script instead to run the application seemed the better method. The application launches fine, infact the console application inside the .app is also added now to the Accessibility panel.
Unfortunately, the Accessibility side of things is still not working and I've run out of ideas?
Any help will be appreciated.
Many thanks in advance.
Is it possible for a Win32 Console Application to be used as a Windows service?
Normally this wouldn't be an issue using C#, .NET, and Visual Studio 2010 or higher, but this is a legacy application that was written in C++ using the Visual C++ 6 environment.
Mainly for the ability to restart itself after a crash.
Is it possible for a Win32 Console Application to be used as a Windows service?
Yes. In fact, many services are written as console apps. Even MSDN examples are.
The app's main() simply needs to call StartServiceCtrlDispatcher() to establish a link to the Service Control Manager:
Writing a Service Program's main Function
Mainly for the ability to restart itself after a crash.
The correct way to handle that is to just let it crash. Use ChangeServiceConfig2() to configure the service's SERVICE_CONFIG_FAILURE_ACTIONS info. One of the available actions is SC_ACTION_RESTART.
Context
I am migrating an installer for an ActiveX control from Per-Machine to Per-User. I did this by programming the installer write to HKCU\Software\Classes instead of HKLM\Software\Classes.
Problem
On my machine (Windows 7 with UAC Enabled), the ActiveX control successfully loads. On the other windows 7 test machines (one with UAC enabled, one with UAC disabled), the control 'partially' loads.
What is Partially?
When a user visits a page with the ActiveX control, Internet Explorer displays a warning message in a yellow bar on the top of the window. If you click the 'Run add-on' button in the bar, the control becomes visible and begins to run, but Javascript code that tries to access properties of the control return the error:
Library not registered.
Differences between machines
On the dev machine reads from HKCR\CLSID\<GUID> succeed while on the test machines these reads fail. Reads from HKCU succeed on both dev and test machines. Reads from HKLM fail on both test and dev machines. (I collected reads using Sysinternals Process Monitor) Strangely, the keys that Internet Explorer fails to read are clearly visible if I use regedit to view HKCR\CLSID\<GUID> on the test machines.
Question
What can I do to get the per-user control to load on the test machines? What could cause this difference between the dev machine and the test machines? Why can I see the key in HKCR with RegEdit but Internet Explorer cannot see the key?
Any help is appreciated. Thank you.
I'm am developing a Firefox extension which interfaces with an underlying Windows service (which I have already made).
During the development so far I encountered one bug in the installer program (which installs the FF extension AND the service). This was due to the security model on Vista requiring elevated privileges to be able to install and start the service. I adjusted the installer and now it installs fine (just with additional Vista'esque warning dialogs being displayed to end-users - which I can live with !)
I am now in the process of developing an XPCOM component that will install along with the XUL stuff I have already made. There will be a XUL javascript interface to the XPCOM which will try to do things like stop and start the service (e.g when user-configuration data is changed).
My question: Since FF will normally be run under a user account, will I run into any difficulties on Vista or other Windows flavors trying to start or stop my own service via XPCOM?
(When users run the installer I don't mind security dialogs popping up in Vista. But I certainly don't want this to happen whenever they try to change their info in the XUL interface.)
What is the correct way to go about this?
Yes, if your service is running as an Administrator then the Firefox process, running as a normal user will not be able to start or stop it. However, it appears that you can use the "sc" command to set access controls on your service from your installer, which means you can allow non-admin users to start and stop your service.
You'll need to use "sc sdset", which is documented (lightly) here:
http://technet.microsoft.com/en-us/library/cc742037%28WS.10%29.aspx
However, to use that, you'll need to read up on the "Security Descriptor Definition Language", which looks kind of complicated:
http://msdn.microsoft.com/en-us/library/aa379567%28VS.85%29.aspx
This blog entry appears to have some human-readable information on it:
http://blogs.dirteam.com/blogs/jorge/archive/2008/03/26/parsing-sddl-strings.aspx