|
No, dont compile then either, i get 21 errors on the BEGIN_SINK_MAP/SINK_ENTRY_INFO macros. 
Tried changing those params every way that seems somewhat resonable with no luck.
/Magnus
- I don't necessarily agree with everything I say
|
|
|
|
|
_Magnus_ wrote:
BEGIN_SINK_MAP(IEHost)
That should probably be BEGIN_SINK_MAP(IEHost<T> )
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
There is a saying in statistics that a million monkeys pounding on typewriters would eventually create a work of Shakespeare. Thanks to the Internet, we now know that this is not true.
|
|
|
|
|
No, that dont make any difference.
Found what it was, ATL7 have added an AdviseEventSink() call in
OnInitdialog() so i got sinked from the wrong class.
Should be possible to get a callstack on the freakin template errors.. 
/Magnus
- I don't necessarily agree with everything I say
|
|
|
|
|
Hi,
The ActiveX control may be used in several occasions simultaneously within one process, but all the control instances are the same one. This is not what I expected,
I think there is some wrong with the project setup, but I do not no where. Can you give me some advice.
Thanks in advance!
|
|
|
|
|
Never heard about - they reside in the same dll (of course) that is loaded once to the process = they share the static parts and global variables , but the instances are always created by the new operator using the class factory.
Only think you can do is to change the class factory from standard to some singletone implementation, but this cannot be done accidentally or through some project setting AFAIK...
Can you be more specific?
|
|
|
|
|
I have some wise of the problem,it is because I implemented all the interfaces in the header file.
And there is another question, can I restrict the sharing
of the global variables?
Tnank you!
|
|
|
|
|
Sorry for delay, I had to travel a bit.
Hmm, only way how to restrict sharing of global variables is to... well... make them non-global
|
|
|
|
|
Say I have a COM object that I want to create inside a library, modify something internally and then pass it on to something externally would the folling seem an okay thing to do in ATL:
IThingy *pIThingy NULL;
HRESULT hr = CThingy::CreateInstance(IID_IThingy, &pIThingy);
if(SUCCEEDED(hr))
{
CThingy *pThingy = dynamic_cast<CThingy*>(pIThingy);
if(pThingy)
{
pThingy->SomeInternalMemberFunction();
}
}
What I'm worried about is casting from an interface pointer to the internal class. Is this okay, or if not why?
It works, most of the time, but when you enable things like #define _ATL_DEBUG_INTERFACES in stdafx.h, then the address acrording to the this pointer internaly to the CThingy instance no longer matches pIThingy that is returned from CreateInstance. Very worrying. Seems to be offset by about 8 bytes.
|
|
|
|
|
Doing such things is in total violation of COM and will not work properly.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
You're going down the inheritance tree (IThingy to CThingy) which puts the responsibility on you to make sure it's safe. If you go the other way, up the tree, it's always safe by C++ language rules:
CComObject<CThingy>* pThingy;
if ( FAILED( CComObject<CThingy>::CreateInstance ( &pThingy ) ))
return NULL;
pThingy->AddRef();
pThingy->SomeInternalStuff();
return (IThingy*) pThingy;CComObject is the most-derived class, derived from CThingy, which is derived from IThingy.
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer.
-- Michael P. Butler in the Lounge
|
|
|
|
|
|
I think it is best we use the QueryInterface() for that.
I also have a question for you guys. How about the reverse? If I already have a pointer to the interface, how can I safely cast it back to the ATL COM class?
I have tried this:
CComObject<cthingy>* pThingy = (CComObject<cthingy>*)pItfThingy;
But the address of the class pThingy is moved back 4 bytes from the original adress, plus the addresses of the internal member variables are skipped one ahead?
It is great if you can help me out here. Thanks in advance.
Trong
Trong
|
|
|
|
|
Hi,
My urgent requirement is to implement Stacked Dialog using ATL/VC++6.0 windowing classes. The implementation is similar to MFC's whcih is provided in the Codeguru site. Can any body tell me how to implement it? Sample code would be greatly helpful.
Thanks,
Sai.
Help Ever, Hurt Never
|
|
|
|
|
I would like my control being able to disply an image such as an icon or a bitmap taking this image directly from the resources of its container, if they are available. Furthermore I would like to give the opportunity of selecting the image at the design time....
The problem is I have been able to access only the resource of the OCX but not those of the container
coul you help me to work it out with this?
thank you
Rob
Or just tell me that this is not possible at all at least!
|
|
|
|
|
An ATL simple object of mathematic stuctures and functions,need overload operator to give facilties to user.
|
|
|
|
|
How to gray checkbox in tree control (from WTL).
|
|
|
|
|
In one class, I have a pointer to a vector of classes defined. In that other class, I have a pointer to a vector of strings defined. I need to access that other class's vector of strings, and I'm having problems with the syntax. Here's sample code.
class MyClass
{
vector<OtherClass> *pvMyClass;
};
MyClass::MyClass()
{
pvMyClass = new vector<OtherClass>;
}
================
class OtherClass
{
vector<string> *pvOC;
};
OtherClass::OtherClass()
{
pvOC = new vector<string>;
}
====================
Later on in the program I do this:
pvMyClass->push_back(OtherClass());
OtherClass::pvOC->clear(); I have tried other syntaxes including, 'pvMyClass->OtherClass::pvOC->clear();', which doesn't work either.
Essentially, I need to retain (until specifically destroyed) as many OtherClass objects that are created, along with their respective vector of strings.
All the proper '#include' statements are present, and I'm using 'namespace std; for both classes.
Thanks for any insight.
William
Fortes in fide et opere!
|
|
|
|
|
The :: syntax works for static variables, which are referenced at the class level. You need an instance of the OtherClass within your MyClass, so you can do this:
myOtherClass->ovPC->clear();
OR make your vector a static variable, which means you'll only have one, visible across all instances of the class.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Thanks for your reply.
Even though I have '#include "OtherClass.h"' present in the file where 'class MyClass' is defined, when in 'MyClass.cpp' (where all the actions are happening) I had the statement:
pvMyClass->pvOC->clear(); the compiler gave an error about 'pvOC' being undeclared (which made sense). That was when I did:
pvMyClass->OtherClass::pvOC->clear(); which took care of the "'pvOC' being undeclared" error, but didn't solve the other sytactical ones (which occurred due to the incorrectness of that statement and it being unacceptable to the compiler).
Subsequent experimental efforts gave encouragements, while others didn't, but none has produced a clean compile even when I did:
class MyClass
{
static vector<OtherClass> vOC;
};
=================
Then later:
vOC->pvOC->clear(); Take my word for it, I've done quite a bit of permutations on this effort and I think I might be beginning to suffer from tunnel vision.
William
Fortes in fide et opere!
|
|
|
|
|
Here's some alternatives that should work. I'll leave it up to you to decide which is the appropriate solution based on your design.
In this first one, I'm assuming that you want to clear the string vector instance in the instance of OtherClass that you're adding to pvMyClass. So, we create an instance of OtherClass, clear pvOC in the instance, then duplicate it into pvMyClass (remember, you can only access elements in STL containers by copying, so if you don't want to create a duplicate instance of OtherClass each time, use a vector<OtherClass*> instead).
class MyClass{
vector<OtherClass> *pvMyClass;
};
MyClass::MyClass(){
pvMyClass = new vector<OtherClass>;
}
class OtherClass{
vector<string> *pvOC;
};
OtherClass::OtherClass(){
pvOC = new vector<string>;
}
OtherClass oc = OtherClass();
oc.pvOC->clear();
pvMyClass->push_back(oc);
In this next one, I assume that all instances of OtherClass share that same pvOC, so I make it static.
class MyClass{
vector<OtherClass> *pvMyClass;
};
MyClass::MyClass(){
pvMyClass = new vector<OtherClass>;
}
class OtherClass{
static vector<string> *pvOC;
};
vector<string> *OtherClass::pvOC =
new vector<string>;
OtherClass::OtherClass(){
}
pvMyClass->push_back(OtherClass());
OtherClass::pvOC->clear();
- Mike
|
|
|
|
|
Thank you very much for your reply. I always gain something from your replies, and this time was no exception.
The first example was more the correct situation. I will use it as a stepping stone for advancing further into what I'm doing. (It's like having a dead car on your hand, then somebody came along and started it up for you. You still haven't gotten to where you're going, but the sound of the engine running again, does lift your spirit and give you hope.)
Thank you.
William
Fortes in fide et opere!
|
|
|
|
|
Hi William,
You may want to change the way that you are declaring your vectors. Under most cases, there is no benefit to declaring a pointer to a vector and then allocating the vector in the constructor. You just end up making the syntax different, and add the need to manually delete the vector in the destructor.
I would end up coding the classes something like this:
#include <vector>
using namespace std;
class OtherClass
{
vector<string> vOC;
public:
void AddString( const char* str )
{
vOC.push_back( str );
}
};
class MyClass
{
vector<OtherClass> vMyClass;
public:
void AddElements();
};
void MyClass::AddElements()
{
vMyClass.push_back( OtherClass() );
OtherClass& oc = vMyClass.back();
oc.AddString( "First" );
oc.AddString( "Second" );
oc.AddString( "Third" );
}
int main()
{
MyClass mine;
mine.AddElements();
return 0;
}
The cleanup of the vectors is handled automatically, with no need to call delete.
Best regards,
John
|
|
|
|
|
Thank you for your input.
The reason for the declaration of a pointer to a vector is to obtain persistency of the vector. IOW, I don't want the vector to be destroyed when processing leaves scope. I will be the one to destroy it when I'm about to exit the program.
William
Fortes in fide et opere!
|
|
|
|
|
When I look at a class like MyClass (in your original post), I would assume that the lifetime of the vector would be the same as the lifetime of the object that contains it. I would control when the vector gets destroyed by controlling the lifetime of the MyClass object, rather than getting a pointer to the vector out of the object.
Similarly, I would assume that the lifetime of the vector inside an OtherClass object should be the same as the object containing it.
For both of these objects, this seemed to be the case, as you were allocating the vector in the constructor of the object. You didn't show a destructor, so I couldn't tell whether you intended to keep the vector after destroying the object.
You might want to rethink this, as it seems that the ownership of the vectors really belong to the objects that contain the pointers.
I don't know what your intentions are, so I am not sure which way I would change this. ( Of course, you can just leave it the way it is... I am just giving my opinion )
If you intend MyClass to be a class that initializes a vector of OtherClass objects, but does not have anything to do with the vector afterwards, I would probably pass a reference to the vector to the constructor of the MyClass object. The ownership of the vector would then be outside of the MyClass object. The vector would persist because it would be declared at a higher level, and passed in to the MyClass object for initialization. The vector object could be declared as high level as you need it to persist, and could be passed by reference to the various routines that need it.
If you intend MyClass to be a class that is a vector of OtherClass objects, I would keep the actual vector inside the object (not a pointer), and make sure that the MyClass object persists (by either declaring it at a high enough level that it remains in scope, or by allocating a MyClass object with new). I personally would lean this way, as I could then add routines to manipulate the vector to the MyClass object.
Best regards,
John
|
|
|
|
|
I am using ofstream to write very large files, of size greater than MAX_LONG. It works fine except for one problem; when the file gets to big I cannot use tellp() to get the file position. It seems a little weird; tellp() returns an fpos<int> object which has a __int64 member in it (returned from get_fpos_t()) -- so I should be able to get the file size out of that member. But once the file size is over 2GB, that member is set to 0. What can I do? I am using Visual C++ 6.
READIN writin rhythmetic
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
