|
Looks like this might be what I want:
stdafx.h:
#pragma once
#include "targetver.h"
#include <stdio.h>
#include <tchar.h>
#include <conio.h>
#include <iostream>
#include <windows.h>
#import "c:\junk\adobe\acrobat.tlb" no_namespace
main.cpp:
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
CoInitialize( NULL );
CAcroApp* app = NULL;
LPOLESTR lpolestr;
StringFromCLSID(__uuidof(AcroApp), &lpolestr);
wprintf_s(L"\n%s", lpolestr);
CoTaskMemFree(lpolestr);
HRESULT hr = CoCreateInstance(
__uuidof( AcroApp )
,NULL
, CLSCTX_ALL
,__uuidof( AcroApp )
,(void**) &app
)
;
wprintf( L"\nHRESULT=%d", hr );
if( SUCCEEDED( hr ) ){
wprintf( L"\nSUCCESS!! : %d", hr );
app->Release();
app = NULL;
return 0;
}else{
wprintf( L"\nFAILED!! : %d", hr );
return 1;
}
}
The best part about this is there aren't any com-specific headers that are NOT included in the VC++ Express Edition.
|
|
|
|
|
Any advice on app scripting? I have a native C++ MFC application running on Windows. I'd like tech-savvy users to be able to write scripts to interact/control the app locally and/or remotely.
I've looked into exposing OLE Automation interfaces, but am not sure thats the best way to go or how easy the remote piece will be for end users.
I want the app to provide the scripting services in process and want to minimize complexity for users developing scripts to control the app locally or remotely.
Anyway, just wondering what the latest thoughts are on the best way to approach this. Any suggestions?
|
|
|
|
|
Your application may host the Windows Script Control [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
How difficult is it to access this from a remote machine?
|
|
|
|
|
I don't know. What exactly do you need to do?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Dear All,
I have a project with so many static variables accessed from one class to another class. I access these static variables by threads.
For example, I access one variable in one thread to change the value and another thread to access it. Both threads are running concurrently. But sometime abruptly the static variable value got changed and it holds a very big value which results in some problem.
I know that I use more static variables and I do mistake in programming but can anyone tell me avoid this kind of problem and why the variable is suddenly holding huge values.
Many thanks in advance.
Kind regards,
Bhanu
|
|
|
|
|
Are you sure all those variables are properly synchronized for concurrent accesses?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
Sorry I don't use any synchronization for the variables. But one thread is reading and another thread is writing. Please help me how to synchronize the variables.
Many thanks for your reply.
|
|
|
|
|
It sounds like you read the variable halfway through being changed. So, the variable is not a trivial type (ie, BOOL).
Look at CCriticalSection, it's probably what you need. There's a million and one way to do this though. You could wrap the variable in a class including the CCriticalSection, and write get / set routines that use the critsect.
It really depends on the fine details.
If you have loads of static variables, it makes me suspect your initial design though. May be worth a second look. Does PlaceA need to know details of PlaceB?
Iain.
In the process of moving to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job! http://cv.imcsoft.co.uk/[ ^]
|
|
|
|
|
Iain Clarke wrote:
If you have loads of static variables, it makes me suspect your initial design though. May be worth a second look. Does PlaceA need to know details of PlaceB?
Yes PlaceA need to know the details of PlaceB. Can you please suggest me a quick way to overcome this problem.
|
|
|
|
|
bhanu_8509 wrote: Can you please suggest me a quick way to overcome this problem.
No, only the slow way of proper design, and wrapping access to complex variables in critical sections.
Iain.
In the process of moving to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job! http://cv.imcsoft.co.uk/[ ^]
|
|
|
|
|
Iain Clarke wrote: No, only the slow way of proper design, and wrapping access to complex variables in critical sections.
Well said, Euclid, with his "there is no royal road to geometry" is a newbie.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
bhanu_8509 wrote: I have a project with so many static variables accessed from one class to another class. I access these static variables by threads.
That's your problem. Is it possible in your case to send messages between threads, rather than accessing static variables directly?
|
|
|
|
|
If the variables are not volatile, you're already in trouble. The ideal way would be to synchronize access to the variable using thread synchronization techniques (a critical section would do, as all your threads belong to the same process).
I see you have a lot of things to read up.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Hello All,
Can some one please tell me how to access the settings in gpedit.msc using VC++?
I need to set/reset various options from the gpedit.msc.
Thanks in advance.
|
|
|
|
|
I think all these options are under "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy"
|
|
|
|
|
Hello,
I am trying some Interop in my application. This is the first time I have had to pass arguments with function calls. I am experiencing some odd results.
RenderEngine.LoadNewMesh("BasicMesh", "Pyramid3", 1);
void RenderEngine::LoadNewMesh(String^ meshType, String^ meshName, int nSubsets)
{
char* cMeshType = (char*)(void*)Marshal::StringToHGlobalAnsi(meshType);
char* cMeshName = (char*)(void*)Marshal::StringToHGlobalAnsi(meshName);
m_engineRoot->LoadMesh.LoadNewMesh(cMeshType, cMeshName, nSubsets);
}
void MeshLoader::LoadNewMesh(char* meshType, char* meshName, UINT nSubsets)
{
m_meshType = meshType;
m_meshName = meshName;
m_nSubsets = 0;
m_nTotalSubsets = nSubsets;
m_pMesh = new BasicMesh();
MessageBox(0, meshName, 0, 0);
if (meshName == "Pyramid3")
MessageBox(0, (char*)"meshName is Pyramid3", 0, 0);
if (strcmp(meshName,"Pyramid3") == 0)
m_meshName = "Pyramid3";
}
MeshManager::CreateMesh(m_pMesh, m_meshName);
MeshManager::GetMeshByName("Pyramid3");
|
|
|
|
|
Mikey_H wrote: if (meshName == "Pyramid3")
the value of meshName is the address of the first character of the string. it is not a string itself. in other words, meshName is a pointer, not a string.
|
|
|
|
|
The third condition here will result true, as does the second
if (meshName == "Pyramid3")
MessageBox(0, (char*)"meshName is Pyramid3", 0, 0);
if (strcmp(meshName,"Pyramid3") == 0)
m_meshName = "Pyramid3";
if (m_meshName == "Pyramid3")
MessageBox(0, (char*)"m_meshName is Pyramid3", 0, 0);
modified on Tuesday, April 14, 2009 12:35 PM
|
|
|
|
|
right, because you've assigned meshName to m_meshName, and i assume m_meshName is a string object of some kind, one with an overloaded "==" operator which knows how to compare a C-style (char*) string to its contents. (CString or std::string?)
the problem with the first remains: you cannot compare a pointer to a static string. that's not how C-style strings work. and that's why strcmp exists.
modified on Tuesday, April 14, 2009 11:39 AM
|
|
|
|
|
|
ah. you're right. i missed that comment.
|
|
|
|
|
The second comparison is the correct one.
Two facts you need to know.
1/ m_meshName is a pointer to character. Underneath, it's an integer holding an address in RAM.
2/ The compiler has seen two constant strings in your code, but only bothers to store one copy of the string "Pyramid3" in it's data segment.
So, the strcmp works as intended, and makes m_meshName point to the constant string in your code.
The 3rd comparison works by luck, as m_meshName is still pointing to that string. This is because your compiler is being efficient, it is not because your code is correct.
You are lucky.
If this doesn't sink in (it's hard until you have a lightbulb moment), I can recommend reading The Complete Guide to C++ Strings, Part I - Win32 Character Encodings[^]
Iain.
In the process of moving to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job! http://cv.imcsoft.co.uk/[ ^]
|
|
|
|
|
Iain Clarke wrote: If this doesn't sink in (it's hard until you have a lightbulb moment)
My lightbulb is on a dimmer switch... I think I understand what you are saying in your reply. I have just read Part 1, will follow up with Part 2 tomorrow, as it is 4.26am.
If my understanding is correct I will be making a lot of changes to my application once I figure this out.
Thank you both for your replies. 
|
|
|
|
|
Hi All,
I am having a common code snippet to be compiled in VC6 and in Embedded vc++(CE). Right now i am working with vc6 part.
void* CNewClass::GetProcAddress1(HMODULE hModule, LPCTSTR lpFuncName)
{
USES_CONVERSION;
#ifdef _WINCE //for wince
LPCWSTR lpUnicodeFuncName = A2W( lpFuncName );
return(GetProcAddress(hModule, lpUnicodeFuncName));
#else // for vc6
LPCSTR lpAsciiFuncName = (LPCSTR)W2A( lpFuncName );
return (GetProcAddress(hModule, lpAsciiFuncName));
#endif
}
Problem: This function (GetProcAddress) returns 0/fails in release mode. It works fine in debug mode.
General Info: The function GetProcAddress resolves to GetProcAddressA or GetProcAddressW based on the build(ascii or unicode) in EVC++ whereas in vc6, it is GetProcAddress only (simlar to GetProcAddressA with LPCSTR as second parameter).
Also just FYI: http://blog.voidnish.com/?p=70[^]
I tried lot of ways to typecastings.. but didnot work. Please help.
Priya Sundar
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
