It's more of an offset in context so it would resemble x86 real mode offset pointers I guess.
"size" seems to be the agreeable term so far about it thus far. Tox pointed me to the size_t typedef which appears as if it would work. However, I'm inclined to use INT_PTR at this point as it should make the code readily understandable once INT_PTR becomes a household typedef methinks.
I want to include a header file (ServeurDicoView.h (hérited from CFormView.h) in a another class ( MySocket )
but when i put #include "CFormView.h"
i have too many errors like error C2146: syntax error : missing ';' before identifier 'm_sListenSocket' as it's explained here :
// ServeurDicoView.h : interface of the CServeurDicoView class<br />
Mot* tabSupp;<br />
MonSocket m_sListenSocket; // the error is here .<br />
in the "Monsocket.h"
// MonSocket.h : header file<br />
#include "ServeurDicoView.h" // if i don't put this .h file .. i have nothing wrong in the ServeurDicoView.h
thanx for readin' my message .... and certainely for answering me
i can't compile the "Monsocket.h"...
-- modified at 11:03 Wednesday 24th May, 2006
The view class is also dependent on the document class. If your going to couple your class to the view like this, you will also need to inclide the document class. (order of inclusion is important but I forget which one comes first). Also, it may take some jacking around with where your declarations are if they are shared by multiple classes. Sometimes forward declarations work, sometimes putting it in the stdafx.h etc...
Lastly, I hate it when others say "you shouldn't do it this way" but for what it's worth, just a friendly FYI, and I still resort to this from time to time so I'm guilty of it as well, but you should try to avoid close coupling your classes to the view/doc/app classes to promote simpler reuse. Sorry. It seems to be our civic duty to point that out around here till it's pouring out of our ears. For what it's worth...
Why does the boost::weak_ptr throw an exception when I'm trying to
construct an shared_ptr from it, if the weak_ptr has not been initialized?
Wouldn't it make more sense if the shared_ptr would be initialized
as an empty_ptr? (I have to check for emptyness anyway!)
Because of this I need an additional try-catch-block (in this case for
checking an integer value in the object pointed to)...
For standard toolbars the Studio creates a 16-color bitmap and puts all icons into that single bitmap. But what if you use third party controls that supports high-color icons, how do you manage your icons? Currently I have all icons in individual bmp files which I add to my resources and then set the icons manually at runtime, which is pretty painful. I also gave up to put them all into a single bitmap because I had to count the pixels to know where the new icon begins.
I would like to have a set of 16-color bitmaps and one with 24-bit, maybe 32-bit with alpha channel.
How do you manage your icons? Any tool recommendation?
Create bitmap in any tool you like, then import in into VS. I'm using http://www.awicons.com/awicons.html, but any special icon editor will do.
When you will need to edit bitmap, just open it in external tool, without doing anything in VS.
I feel that I really should know this, but I'm having an off-day, and I've just been told my car needs new wheel-bearings, a brake caliper and disc on one of the wheels, which would at least explain why I keep having to turn the radio up
I have a function int __cdecl xxx(const char* value, ...) which is in a C DLL. I'm writing a wrapper class which loads the DLL and and does a GetProcAddress to retrieve the function address. So far so good. Except that for my wrapper class, I'm providing a wrapper::xxx member which (having checked the DLL is loaded and the proc address isn't null) will call down through the pointer.
So I have
int xxx(const char*value,...)
as a member function, and
int (__cdecl *m_pf_xxx)(const char*,...)
as a member too.
What incantation do I need to get my class function to call via the pointer?
If it wasn't for the variable args, it would be
but of course, I need to pass the other args if there are any...
The reason for doing it this way is that the DLL is a 3rd party one (one of a set, in fact), which is loaded at runtime. I can't simply delayload, since the DLL is specified by configuration at runtime, and the wrapper class handles multiple similar ones (think of a codec, for instance).
Like I say, I ought to know this; and before anyone suggests it, I can't change the DLLs, since they are 3rd party, and the developers are not interested in changing them (of course). Trouble is, I'm tied to using them in this instance.
Thanks Chris, that's exactly what I was afraid of.
The 3rd party are adamant that they won't change their code, but since the function in question is a 'convenience' one, I think I can emulate what it's doing, making calls to other functions within the DLL anyway. Having looked at stack frames, I can see why it wouldn't be possible.
I don't even want to think about playing with the stack frame to try and jump to the code, writing the emulation code in the wrapper would be much easier & faster...
I am interested in direct record on CD. I wish to write on CD without IMAPI.
It should be the noncommercial library. For example, Nero SDK demands, that has been installed Nero. That not suits me fine.