|
the #import directive is like this:
#import "D:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB"
while compiling,errors generated as below:
Compiling...
temp.cpp
E:\emmai\temp\temp.cpp(8) : error C2772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
e:\emmai\temp\debug\vbe6ext.tlh(212) : error C2146: syntax error : missing ';' before identifier 'CommandBars'
e:\emmai\temp\debug\vbe6ext.tlh(212) : error C2501: '__missing_type__' : missing storage-class or type specifiers
e:\emmai\temp\debug\vbe6ext.tlh(212) : error C2501: 'CommandBars' : missing storage-class or type specifiers
e:\emmai\temp\debug\vbe6ext.tlh(233) : error C2146: syntax error : missing ';' before identifier 'GetCommandBars'
e:\emmai\temp\debug\vbe6ext.tlh(233) : error C2501: '__missing_type__' : missing storage-class or type specifiers
e:\emmai\temp\debug\vbe6ext.tlh(255) : error C2061: syntax error : identifier '__missing_type__'
e:\emmai\temp\debug\vbe6ext.tli(32) : error C2143: syntax error : missing ';' before 'tag::id'
e:\emmai\temp\debug\vbe6ext.tli(32) : error C2433: '__missing_type__' : 'inline' not permitted on data declarations
e:\emmai\temp\debug\vbe6ext.tli(32) : error C2501: '__missing_type__' : missing storage-class or type specifiers
e:\emmai\temp\debug\vbe6ext.tli(32) : fatal error C1004: unexpected end of file found
Error executing cl.exe.
temp.exe - 11 error(s), 0 warning(s)
I Love This Game!
|
|
|
|
|
Hi!
I get a ATL object by other object's method. like below
STDMETHODIMP CBanana::GetApple(IApple** apple)
{
CComObject<CApple>* p =NULL;
CComObject<CApple>::CreateInstance(&p);
p->QueryInterface(apple);
return S_OK;
}
But i dont know how to turn it back( from interface to real class). the code list below seems doesn't work.
STDMETHODIMP CBanana::DoSomethingOnApple(IApple* apple)
{
CApple* p = dynamic_cast<CApple*>(apple);
p->num = 3;
}
I think dynamic_cast can't be used in this situation. But i really don't know the proper way.
Would you please lend me a hand? I have blocked in this problem for almost one week.
|
|
|
|
|
You don't have to convert it back. If you look at the definition of CComObject<> you'll see:
template <class Base>
class CComObject : public Base
which means that CComObject<Base> inherits from Base. Everything Base has to offer, so will CComObject<Base>.
--
Serial killers don't kill their boyfriends.
|
|
|
|
|
I dont understand. I try to convert IApple into CApple or CComObject<capple>. Any idea?
|
|
|
|
|
Why do the conversion to IApple to begin with? It is possible, but very unsafe, see peterchens answer down below.
A rule of thumb is to convert to IApple's just before they leave a method defined in a COM interface.
--
You know me. I sure know you.. Everyone of you!
|
|
|
|
|
novachen wrote:
But i dont know how to turn it back( from interface to real class
Rule of thumb: You must not, because your apple might sit on a server in Siberia.
Long answer: Unless you know 100% that the class implementing IApple was created on the same machine, in the same process (a few registry entries could easily break that). One of the fundamentals of COM is that you can never assume anything about the Implementing class, only abotu the interfaces.
The bad thing is, it works most of the time, for inproc servers, so people try it.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Thanks!
But in fact, I try to hide a complex structure inside COM interface. On the interface of COM, Apple is a very simple object, but in the eyes of the other objects in the same COM dll, Apple has more content than the interface.
So i hope IApple can turn back into CApple, that i can access the hid part. I can't confirm the objects sit with client at same computer, but i can confirm those objects access each other on the same server.
How can i achieve this design?
|
|
|
|
|
You cam
1. Make Apple only creatable by Banana
2. Tag each Apple instance with a GUID, that can be queried through the IApple interface
3. Keep a map<GUID, CApple *> to retrieve the CApple * belonging to an IApple *
4. Reject each IApple you get that you don't know.
I have a slightly simpler case, that uses a slightly simpler implementation:
Noone passes an IApple back to me (I just hand it out), and the apple doesn't have any state that can't be dereived from Banana. So I let the Banana implement the methods of Apple and make the IApple implementation forward the calls to it's Banana. Some care with avoiding circular ref's is all to take care of.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Sorry if I waste some bytes on this forum now, but I can't
get this to work as i thought it would.. My questions are:
1) Why don't the DerivedList1 and DerivedList2 seem to
inherit the count() and the two get_instance()-methods?
For me, they don't pop up in under the classes in the
"Class view"-tab.
and...
2) ..what must I do to make them  So maybe just an an-
swer to the first question will be enough.
Code goes here
-------------------------------------------
#ifndef MY_HFILE_H
#define MY_HFILE_H
#include <list>
using std::list;
#include <string>
using std::string;
class Class1;
class Class2;
template<class T>
class GenList : public list<T*> {
public:
virtual string to_string(Class1* receiveObj, bool check=true);
int count(string key);
bool get_instance(int nr, T* dest, int& instance_nr);
bool get_instance(string key, T* dest, int& instance_nr);
};
class DerivedList1 : public GenList<Class1> {
public:
string to_string(Class1* receiveObj, bool check=true);
};
class DerivedList2 : public GenList<Class2> {
public:
string to_string(Class1* receiveObj, bool check=true);
};
#endif // #ifndef MY_HFILE_H
-------------------------------------------
Thank you for any input on this
/P
|
|
|
|
|
petter_e wrote:
Why don't the DerivedList1 and DerivedList2 seem to
inherit the count() and the two get_instance()-methods?
They do.
petter_e wrote:
For me, they don't pop up in under the classes in the
"Class view"-tab.
That's because they are actually members of the base class.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
> That's because they are actually members of the base class.
Yes, but they should still show up! My bet is on a intellisense/template bug. 
--
Serial killers don't kill their boyfriends.
|
|
|
|
|
Jörgen Sigvardsson wrote:
Yes, but they should still show up! My bet is on a intellisense/template bug.
Aaah. He's not talking about intellisense. He's talking about ClassView . Inherited functions don't appear there, but, as you said, should appear in the intellisense window.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you for your entries!
Meanwhile, i have struggled with this stuff (somehow
it felt familiar in a worrying way).
My real problem with this wouldn't be wether the methods
showed up or not, it was merely a symptom in line with was
bothering me: I could not _access_ the methods either (from
the DerivedLists) - maybe I should have mentioned that, too.
What I was doing was of course that I 1st hadn't defined the
functions, so I wasn't worried about not being able to use them
at that point. I just wrote them BUT! (moan) I placed them in a
.cpp-file of their own. So they weren't visible or what the
term is (and still not showing in the Class view), and I just
got complaints of unresolved externals for them when linking.
It was a year ago (but under some command line compiler) I did
battle a while with some template things and for the 1st time
realized I should place the template class' member functions
in the same file. This was my 2nd revelation. Hope I need no 3rd
Thanks again for your input!
Regards
/Petter
|
|
|
|
|
Hi everyone. I have an MFC app which usesDAO to access Jet/Access databases. The development machine is Win2000 sp3 with Visual Studio 6 installed. The app is statically linked so MFC DLL version conflicts shouldn't be an isue. The app works 100% of my development machine, but I tried it on a Win98se machine and it won't open a Jet database file. The Win98se machine has DCOM98 and MDAC 2.5 installed on it, and only necessary software installed. Only my app is running whne I tested it. The app runs fine until I attempt to open a database. The code below is how I open the database
<br />
CDaoDatabase* db;<br />
CEDaoRecordset* rs;<br />
CString strSQL;<br />
long int lTemp;<br />
<br />
try<br />
{<br />
db = new CDaoDatabase();<br />
db->Open(strDBPath, FALSE, TRUE, _T(";PWD="));<br />
rs = new CEDaoRecordset(db);<br />
<br />
strDBPath is the path to the DB Jet database file, which is known to be valid, and not read-only.
Once it hits db->Open() I get an "unknown exception" error and the program closes.
I know it could be anything, but does anyone have any ideas as to what could cause this? Did I forget to install something? The app is MBCS based, not unicode.
|
|
|
|
|
Have you caught the exception and analyzed it? You should be able to get detailed error information if you use try{}catch{} and take a look at the error codes being returned.
Are you 100% sure that the database itself was copied over exactly? If both machines are trying to access the same DB, then you may want to look at the DB driver versions installed on each machine. Your development platform may be using different drivers.
|
|
|
|
|
I am making a small Win32 API application. I wanted to have a coloured background. When I tried to handle WM_ERASEBKGND, I got too much flicker. I tried to make a memory dc and use it, but that did not improve the flicker. Is it something I do wrong? Could you please show me how to handle WM_ERASEBKGND without flicker?
Note: I noticed that the flicker was gone when I created a brush and made myWndClass.hbrBackground point to it. But the problem is that I may want to draw in WM_ERASEBKGND, not just have a single brush.
<marquee behavior="alternate">Hosam Aly Mahmoud
|
|
|
|
|
Do everything in response to WM_PAINT and use a memory DC. Handle WM_ERASEBKGND and do nothing there.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you for your reply. I thought that WM_PAINT would only allow me to draw a certain region of the window, not all of it. Also, the docs said that to make a background (for example a picture) you should handle WM_ERASEBKGND. Am I wrong?
<marquee behavior="alternate">Hosam Aly Mahmoud
|
|
|
|
|
Hosam Aly Mahmoud wrote:
I thought that WM_PAINT would only allow me to draw a certain region of the window, not all of it.
The device context given as a parameter to a WM_PAINT message is set up to only draw to the regions of the window which have been invalidated. By definition, any region that is not invalidated, does not need painting, so you shouldn't have a problem.
Hosam Aly Mahmoud wrote:
Also, the docs said that to make a background (for example a picture) you should handle WM_ERASEBKGND. Am I wrong?
WM_ERASEBKGND is sent whenever InvalidateRect() or InvalidateRgn() are called with fErase=TRUE. If the fErase flag is FALSE, then WM_ERASEBKGND is not sent. It is quite ok to draw the background in WM_PAINT however. In fact, to get true flicker-free drawing, it is the only way.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Many thanks for your reply. I am using Win32 API, so I get the HDC using BeginPaint(). I tried to draw in WM_PAINT, but I get a white background although I have myWndClass.hbrBackground = NULL. Here is my code:
case WM_PAINT:
{
static PAINTSTRUCT ps;
static dc = BeginPaint(hWnd, &ps);
static HDC memDC = CreateCompatibleDC(dc);
static HBITMAP memBitmap = CreateCompatibleBitmap(dc, MainWindowRect.right, MainWindowRect.bottom);
SelectObject(memDC, memBitmap);
FloodFill ( memDC, 20, 20, RGB(255,0,0) );
static HBRUSH oldBrush = (HBRUSH) SelectObject(memDC, myBrush);
Rectangle(memDC, myRect.left, myRect.top, myRect.right, myRect.bottom );
SelectObject(memDC, oldBrush);
BitBlt(dc, 0, 0, MainWindowRect.right, MainWindowRect.bottom,
memDC, 0, 0, SRCCOPY);
EndPaint(hWnd, &ps);
return 0;
}
case WM_ERASEBKGND:
return 0;
<marquee behavior="alternate">Hosam Aly Mahmoud
|
|
|
|
|
Remove the static keyword from all of your variable declarations and try again.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I did it but no difference. 
<marquee behavior="alternate">Hosam Aly Mahmoud
|
|
|
|
|
Hosam Aly Mahmoud wrote:
FloodFill ( memDC, 20, 20, RGB(255,0,0) ); // red background
 I should have seen this before...
The colour you pass to FloodFill() is not the colour of the fill. It's the colour of the border. FloodFill() fills the area with the currently selected brush. To fill a rectangle with a given colour, either create a solid brush (CreateSolidBrush()) and use Rectangle(), or use the ExtTextOut() function to draw opaque text without actually drawing text:
SetBkColor(memDC, RGB(255,0,0));
RECT rect;
ExtTextOut(memDC, 0, 0, ETO_OPAQUE, rect, NULL, 0, NULL); Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you very much! That really helped!
Now I am wondering, if I want to make the background an image, should I do it in response to WM_PAINT too? Why is WM_ERASEBKGND available then? Why did they put it if I should draw in WM_PAINT?
Thank you very much for your patience! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
<marquee behavior="alternate">Hosam Aly Mahmoud
|
|
|
|
|
Hosam Aly Mahmoud wrote:
Now I am wondering, if I want to make the background an image, should I do it in response to WM_PAINT too?
Yes. That will work fine
Hosam Aly Mahmoud wrote:
Why is WM_ERASEBKGND available then? Why did they put it if I should draw in WM_PAINT?
There is nothing wrong with using WM_ERASEBKGND for drawing the background. It's simply not possible to do flicker-free drawing using it. I'm not certain why it's there - it's probably been there since Windows 1.0
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
