|
When you run an application from inside Visual Studio, the working directory is the directory containing the project files (.vcxproj, .sln). However when you run outside of VS, the working directory is the one containing the .exe file.
So if you are opening an html file with just a file name (e.g. open "MyTest.html") then that file must exist in the working directory. You should use full path names to avoid this problem. (You can use GetModuleFileName to find out the directory containing your exe).
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
I understand this, I have been using the full path and file name.
I need to convert the string to a BSTR, I'm assuming i'm doing it correctly because as I say, the program works but only shows a web page when I run it from visual studio.
here's how:
char url[MAX_PATH];
GetModuleFileName(InstanceHandle, url, MAX_PATH);
std::string file = url;
file = file.substr(0, file.find_last_of("\\"));
file += "\\Help.html";
MessageBox(NULL, file.c_str(), NULL, NULL);
OLECHAR* oleChar = NULL;
oleChar = (OLECHAR*)calloc(file.length(), sizeof(OLECHAR));
MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, file.c_str(), -1, oleChar, sizeof(WCHAR)*file.length());
vURL.bstrVal = SysAllocString(oleChar);
|
|
|
|
|
I've got the program to work  ! after some modifications. still not sure what the problem was but I think it had something to do with structure declarations I'd placed in a header file..
|
|
|
|
|
So I use a lot of function pointers in C, and wanted to add one to a C++ class (MFC).
So I start off with a typedef in my class:
typedef ULONG (MyClass::*MyFunc)(PULONG, PVOID);
The call back:
ULONG MyFunc(PULONG, PVOID);
Another func that takes the callback as a parameter:
ULONG SomeFunc(PULONG, MyFunc, PVOID);
I then write the implementaiton of SomeFunc:
ULONG MyClass::SomeFunc(PULONG pVal, MyFunc pProc, PVOID pOpt)
{
...
}
To call the callback from inside MyClass::SomeFunc() I had to use this syntax:
ULONG ret = (this->*pProc)(&x, NULL);
I couldn't just call (*pProc)(&x, NULL); I had to add the 'this->'.
What a crappy syntax. You dont have to call other member funcs with a 'this->' so why is it required for function pointers?
--edit--
Perhaps it would look better as: (*this.*pProc)(&x, NULL);
Nah, thats WAY to much direction...
==============================
Nothing to say.
|
|
|
|
|
Fat__Eric wrote: What a crappy syntax. You dont have to call other member funcs with a 'this->' so why is it required for function pointers?
probably because whoever designed C++ was kind enough to mandate an implicit this-> for member fns, because calling member fns is a very common situation, but didn't bother for member fn ptrs, because that's much less common.
you can just make a macro for that ugly syntax
|
|
|
|
|
Chris Losinger wrote: probably because whoever designed C++ was kind enough to mandate an implicit
this-> for member fns
You dont need to specify 'this->' when calling member funcs, you just call them by name. Thats the point I am making.
Chris Losinger wrote: fn ptrs, because that's much less common.
Used a lot in C though. A heck of a lot. Surprises me they werent better catered for in C++.
Chris Losinger wrote: you can just make a macro for that ugly syntax
Yeah, it sure is a pigs arse.
==============================
Nothing to say.
|
|
|
|
|
Fat__Eric wrote: Used a lot in C though. A heck of a lot. Surprises me they werent better catered for in C++
Possibly because C++ doesn't encourage C-style programming.
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]
|
|
|
|
|
Yet there are a lot of functions in the Win32 API that use call backs.
==============================
Nothing to say.
|
|
|
|
|
The Windows API is more C than it is C++.
|
|
|
|
|
Are you suggesting that C++ was designed to be incompatible with the win 32 API?
==============================
Nothing to say.
|
|
|
|
|
Well... since all my C++ Win32 programs seem to work, I guess that can't be it, right? 
|
|
|
|
|
For that to be true, the win32 Api would have had to exist first. (it didn't)
|
|
|
|
|
Fat__Eric wrote: Yet there are a lot of functions in the Win32 API that use call backs.
C++ wasn't designed to favour Win32 API integration, I guess. Anyway there you don't need this, in fact the wrappers for Win32 API callbacks are (usually) static C++ methods.
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]
|
|
|
|
|
Yeah, and the calling back mechanism is of course in the win32 api so it is ignorant of C++.
Anyway, it strikes me as a particularly daft limitation to have to specify 'this->' when legally just (*proc) is valid (since C++ extends the C language).
==============================
Nothing to say.
|
|
|
|
|
That wouldn't be a method call, that would be a function call (i.e. the syntax would be indistinguishable).
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]
|
|
|
|
|
CPallini wrote: That wouldn't be a method call, that would be a function call (i.e. the syntax
would be indistinguishable).
Are you saying it is the same as C? It isnt.
==============================
Nothing to say.
|
|
|
|
|
Why not?
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]
|
|
|
|
|
Thats what this thread is all about.
If you want to call a funciton pointer in a class for another member of that class you cant just call (*pProc)(), you need to prefix it thus: (this->*pProc)(). ( or (*this.*pProc)(), whci is cleaner, though VS hates it).
==============================
Nothing to say.
|
|
|
|
|
Well, if you remove this then the syntax would be exactly (or, at least compatible with) the one used for bare C functions. That would be a bit ambiguous.
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]
|
|
|
|
|
If you remove the this-> it doesnt compile.
==============================
Nothing to say.
|
|
|
|
|
That's my point. It shouldn't compile (it would be ambiguous).
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]
|
|
|
|
|
Fat__Eric wrote:
You dont need to specify 'this->' when calling member funcs, you just call them by name. Thats the point I am making.
right. and the point i'm making is that the C++ designers made the 'this->' implicit when calling a member function directly from inside the class: the compiler simply assumes a call to non-static member fn CFoo::Whatever() from inside a class is the same as a call to this->Whatever() - they just let you omit the 'this->' for such a common case. but the C++ authors didn't provide for that little bit of syntactic shortcut when dealing with member fn ptrs. maybe there's a subtle technical reason they didn't give the same shortcut for member fn ptrs, but i haven't been able to find it. it seems obvious that if you can assume 'this' for a normal member fn call, you can assume this for a member fn ptr call.
Fat__Eric wrote: Used a lot in C though. A heck of a lot. Surprises me they werent better catered for in C++.
but not so much in C++. i can count the number of times i've used them in C++ on one finger - and that was when doing a quick-n-dirty conversion of an old C program to C++.
|
|
|
|
|
The reason was it was ambiguous.
They could have provided a different dereferencing operator for member function pointers, something like ::* maybe, but alas they didn't.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
ahmed zahmed wrote: The reason was it was ambiguous.
no, it isn't. or, it wouldn't be. (it is now, since the C++ rules don't allow for this kind of thing, but that's not my point)
the compiler already knows how to do the implicit 'this' with member functions. it could do the same thing with member fn ptrs. assume unqualified member references are to 'this'. if a member function pointer for the class is used inside a non-static member function? assume 'this'.
|
|
|
|
|
yes, it could do that, but then calling a c-style function pointer would need a new syntax then.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
