I am trying to figure out how to get GraphEdit to show me my running graph from my app. I running windows 7 64bit.
In the directshow sdk samples they have a spot for registering with the rot. I read on M$'s site that I needed to register the droppage.dll(cant recall the exact name right now). So I did that, but still no dice.
Any idea's?
Remember that on a 64-bit machine, you will need to use the 64-bit graphedt and 64-bit proppage.dll for your 64-bit app (and 32-bit graphedt/proppage for a 32-bit app). And if you are in admin mode with VS, you will need to be in admin mode for graphedt.
Related
I am running windows 7 64bit and
I am trying to set up SDL on my school laptop which I do not have admin rights for.
The project compiles fine but when I try to run it I get an error saying " the application was unable to start correctly (0xc000007b)." I Have experienced this error before when trying to run the same 32bit program on my 64bit computer at home. By compiling using 64 bit methods the issue was resovled however I do not have access to a 64bit compiler on my school laptop because I cant find any compilers that don't require admin rights to set up. So If you know of a 64bit compiler download that requires no ADMIN rights to install or if you have an alternate method I would appreciate it.
My stats
Code_blocks 12.11
SDL 1.2.15
SDL_image1.2.10
The compiler that came with codeblocks From Here http://www.codeblocks.org/downloads/26#windows
codeblocks-12.11mingw-setup_user.exe
try tdm-gcc: http://tdm-gcc.tdragon.net/
as for 0xc000007b problem:
it may occur when you don't have a working 32bit directx on yout 64bit system, you should update your directx, this may help solve the problem.
directx update: http://www.microsoft.com/download/details.aspx?id=35
I have built and deployed Dvorak SIP sample from C:\Program Files\Windows Mobile 6 SDK\Samples\PocketPC\CPP\ATL\dvoraksip location. The sample successfully deploys and registers and when I click on Dvorak from the SIP icon at the middle of the tray it is opened in Windows Mobile 5 emulator and some other devices except Pidion BIP-1300-GSM which is running Windows Mobile 5.0.
What is the reason?
I should mention that it is always deployed and registered successfully.
UPDATE
I put DebugMessage in all of the methods.
When I Deploy Dvorak, methods in dvoraksip.cpp are called on device like what happens on Emulator.
When I click the icon in tray in Emulator methods in dvorak_implementation.cpp are called correctly but nothing is called on Pidion device.
I don know what possibly went wrong on your side. There are some pitfalls when using this WM653 sample on Windows Mobile 5. When you switch to WM5 in VS8 configuration manager, the deployment settings have to been adjusted:
Do you have WM5 SDK installed within VS2008 too?
In VS8 ensure that you link ATL statically:
Here is my updated VS2008 project/solution of DVORAK SIP sample using WM5 SDK: http://www.hjgode.de/temp/dvoraksipVS2008_WM5SDK.zip
I tested that on a WM5 device (no Pidion, an Intermec CK60 running WM5):
I have seen that you posted the same question at social.msdn and who knows where too. If the pidion still does not work like a WM5 device, you should consider changing the model.
As an alternative you may use Richard Boling's NumPanel example of a SIP.
Here is the VS8 solution for WM5SDK: http://www.hjgode.de/temp/BolingNumPanel.zip
Well, I am facing a strange problem. I have developed a sample MFC ribbon application on my machine - Windows 7 , with Visual Studio 2008. When I copy paste the .exe onto my laptop and run the app , I don't see the ribbon menu (in fact the app has not menu now) .
I have tried looking up the .dll that load in each case(on my work machine and laptop) using process monitor but I am unable to locate what I might be missing. Any help will be greatly appreciated.
Edit 1 -
Ok, So thanks for your responses. Some progress has been made with this issue
I changed my IDE to VS 2010. The ribbon was coded manually and I figured out if I could add it as a resource maybe the problem would be solved. VS 2008 did not have the option of adding a ribbon as a resource.
I installed the VS 2010 Service Pack Redistributable X86/X64 depending on whether the machine is 32 or 64 bit.
I built a new "ribbontest.exe" app from VS 2010 and deployed it on other machines on which I would test my actual app. The ribbon for "ribbontest.exe" loads without any problems.
When I deploy my app and run it, first the old menubar loads for a sec or two, then the ribbon flashes and disappears.
A little history of the app I am referring to -
Initially my application had the menubar view. I followed this article http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm to accommodate a ribbon.
Any suggestions?
Most likely there's a conflict in the settings 'paths'. In your InitInstance() handler, you've got a statement like this:
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need
// Change the registry key under which our settings are stored
SetRegistryKey(_T("yourappname"));
If you haven't changed that name yet, do it. If you did, open regedit.exe on your target machine and remove the whole key under HKCU\Software\yourappname and then try again.
MFC stores user customizations of Ribbons/Menus/... under that key. But if you changed your app those settings don't necessarily match anymore and you can end up with stuff not showing correctly or not at all.
Make sure you download and install the Visual C++ Redistributable Runtime on your destination machine: http://www.microsoft.com/en-us/download/details.aspx?id=29
Or, something like it. Make sure you have architecture (x86/x64) correct and make sure it matches with the service pack version you compile with.
Joe is right: you need redistributable.
Joe is right: you cannot run 64-bit program on 32-bit machine.
All of the above would be indicated by the system (missing DLL, configuration incorrect, or 64/32 bit discrepancy)
Joe is right: your application must be built for specific set of minimum Windows version and service pack.
In addition to Joe’s post you must run release build not debug build.
If all of those requirements are met and you still have this problem, try linking MFC statically and see if problem persists.
I'm trying to register redmon monitor on Windows 7 64 bit. Here is an example of code I use:
MONITOR_INFO_2 info;
info.pName = "RedmonMonitor";
info.pEnvironment = "Windows x64";
info.pDLLName = "redmonnt.dll";
SetPrivilege("SeLoadDriverPrivilege",TRUE);
AddMonitor(NULL, 2, (LPBYTE)&info);
It works perfectly on WinXP with "Windows NT x86" environment specified. On Windows 7 AddMonitor() returns FALSE, GetLastError() returns 0.
At the moment of calling redmonnt.dll already copied to "C:\Windows\system32" (also it automatically appears at "C:\Windows\SysWOW64").
Also I experimented with Wow64DisableWow64FsRedirection() as suggested here, didn't help.
I tried "Windows NT x86" and "Windows x64" environment values.
Using thoughts from here regarding privileges tried to launch program as administrator, didn't help.
redmonnt.dll taken from redmon17 package from the official site.
SetPrivilege() taken from msdn examples with small modifications.
Would be grateful for any ideas on how to make this work.
Thank you.
Which version of redmonnt.dll you use? Is it 64-bit DLL or 32-bit version from the official site? The DLL will be loaded by spoolsv.exe which is 64-bit application on the 64-bit operation system. So you have to use 64-bit version of the DLL.
To pop up the UAC dialog in Vista when writing to the HKLM registry hive, we opt to not use the Win32 Registry API, as when Vista permissions are lacking, we'd need to relaunch our entire application with administrator rights. Instead, we do this trick:
ShellExecute(hWnd, "runas" /* display UAC prompt on Vista */, windir + "\\Reg", "add HKLM\\Software\\Company\\KeyName /v valueName /t REG_MULTI_TZ /d ValueData", NULL, SW_HIDE);
This solution works fine, besides that our application is a 32-bit one, and it runs the REG.EXE command as it would be a 32-bit app using the WOW compatibility layer! :( If REG.EXE is ran from the command line, it's properly ran in 64-bit mode. This matters, because if it's ran as a 32-bit app, the registry keys will end up in the wrong place due to registry reflection.
So is there any way to launch a 64-bit app programmatically from a 32-bit app and not have it run using the WOW64 subsystem like its parent 32-bit process (i.e. a "*" suffix in the Task Manager)?
try this (from a 32bit process):
> %WINDIR%\sysnative\reg.exe query ...
(found that here).
Whether a 32-bit or 64-bit native (unmanaged) program is run depends solely on the executable. There are two copies of reg.exe, in C:\Windows\System32 (64-bit) and C:\Windows\SysWOW64 (32-bit). Because you don't specify a path, you're getting whatever appears first in the PATH environment variable, which is the 32-bit version for a 32-bit process.
You should really factor this function out into a separate program or COM object, and mark the program with a manifest, or launch the COM object using the COM elevation moniker.
Have you considered creating a small "helper" application to make the registry update for you? If you compile it to 64bit and include a manifest that indicates it requires administrator rights, then it'll cover both bases for you.
There are API's to detect the "bitness" of the OS you're running on so you could, conceivably, compile both RegistryUpdate32.exe and RegistryUpdate64.exe and call the relevant one.
One thing that I've done as a solution for myself is to PInvoke disabling redirection:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365744(v=vs.85).aspx
You can always turn it right back on.