|
when calling msflexgrid::clear() for example the program fails in this line
ASSERT(m_pCtrlSite != NULL); in the vs/src/WINOCC.cpp file
|
|
|
|
|
Are you calling AfxEnableOleAutomation() or CoInitialize() in your InitInstance function?
Usually you get those types of assertions when you haven't initialized COM.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
how can i initialize COM? and what's the declaration for these two functions?
|
|
|
|
|
identity_85 wrote: how can i initialize COM?
By using one of the two functions that Zac mentioned.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: identity_85 wrote:
how can i initialize COM?
By using one of the two functions that Zac mentioned.
This is about the time where I would tell him to take his hands off the keyboard, go to Barnes and Noble, buy any Intro to C++ book and any Intro to COM book ... and not to touch the keyboard again until both have been read and understood ... *sigh*
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: This is about the time where I would tell him to...go to Barnes and Noble...
Be sure to include directions.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
program fails cause in ASSERT(m_pCtrlSite != NULL); "m_pCtrlSite" not an OLE control ?? will these two functions solve it and if so what's the directions or classes of them plz?
|
|
|
|
|
identity_85 wrote: will these two functions solve it
Very doubtful. Had you failed to initialize COM, the application would have most likely failed to even start.
I created a dialog-based project and added the Microsoft FlexGrid v6 Control to it. I then added the control to the dialog template. At this point, I could compile and run the application fine. What else do you have in place?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: Had you failed to initialize COM, the application would have most likely failed to even start.
It would have started, but as soon as any access to the control was made, it would have given an assertion (in debug) or just crashed (in release).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: It would have started...
True, in a sense.
Zac Howland wrote: ...but as soon as any access to the control was made, it would have given an assertion (in debug) or just crashed (in release).
Neither of which happened. It just went away quietly.
|
|
|
|
|
Hi,
I'm trying to debug my code, and each time I run into a dynamically-linked function-call, the debugger cannot step-into the function, and does not stop at breakpoints inside it.
e.g.
class ISender {
public:
virtual void Send() = 0;
};
class XSender : public ISender {
...
virtual void Send();
};
ISender *m_sender = new XSender;
m_sender->Send()
Instead, it suggests that it shows the disassembly, as if it cannot find the matching code. I've tried that, and I still can't go inside these functions.
Static calls to functions of the same class work properly, e.g.
ISender m_sender = new XSender;
In addition, The debugger does not show the value of the object in the monitor, unless I specifically cast it to the run-time type of the object, i.e.:
(XSender *)m_sender
I suspect that thesse problems are related but I'm not sure.
Any ideas Thanks.
while (i == live) {
have(fun);
}
|
|
|
|
|
Just a quick thing to check; you say the code's dynamically-linked (ie in a DLL); check the output pane of Visual Studio for the line that loads the DLL the call's in. It should say something like:
'StyleManager.exe': Loaded 'C:\Codebase\codedb\PF\Products\StyleManager\SMCmdLine\Debug\StyleManager.dll', Symbols loaded.
If it doesn't say 'Symbols loaded' for your DLL (instead it'll say 'No symbols loaded.'), then the debugger won't know how to debug into the DLL (other than in assembly view). You'll need to ensure that the DLL is built in debug mode and that the relevant PDB is around. Most of the time this happens automatically, but if you have a custom post-build step that copies the DLL somewhere else but not the PDB then you might get this kind of problem.
|
|
|
|
|
I have two bitmaps (loaded from resources).
I want to combine thse two bitmaps side-by-side into a 3rd bitmap.
I want to put the 3rd (combined) bitmap into an image list.
I tried using the BitmapDC class from the GDI articles section, but I'm missing something (obviously, otherwise I wouldn't be here).
Here's the code I'm using now:
CBitmap bmp1;
CBitmap bmp2;
bmp1.LoadBitmap(nImgConsult);
bmp2.LoadBitmap(nImgLabs);
CBitmapDC bmpDC(34, 21, GetDC(), RGB(255,255,255));
DrawBitmap(&bmp1, &bmpDC, CPoint(0, 0));
DrawBitmap(&bmp2, &bmpDC, CPoint(17, 0));
CBitmap* pBMP = bmpDC.Close();
if (!m_ResultsImages.Replace(0, pBMP, NULL))
{
TRACE("ImageList.Replace failed\n");
}
delete pBMP;
Any hints, clues, or alternative code?
-- modified at 11:36 Wednesday 26th July, 2006
|
|
|
|
|
Why not just use the GetBitmapBits/SetBitmapBits (and CGdiObject::GetObject) to get the bits from images 1 and 2, create a byte array that is the size of the sum of both those arrays (which should be double the size of either one if the bitmaps are the same size), copy the bytes from image 1 to the first part of the new array, and image 2 to the last part of the new array and then use SetBitmapBits on a newly created CBitmap object?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
another approach is create a bitmap sized to fit both source bitmaps. arrange the bitmaps via bitblt()
Kuphryn
|
|
|
|
|
Hi
Can we have two CDocument derived classes in an MDI application??
|
|
|
|
|
|
Thus the name MDI = Multiple Document
|
|
|
|
|
hey can anyone help me sort this? the weird thing is my program ran at first but now if i try and run i get this debug error!
*********************************************************************************************
*": warning C4267: 'argument' : conversion from 'size_t' to 'DWORD', possible loss of data"
*********************************************************************************************
If i'm not dead enough for life, am i alive enough for death?
|
|
|
|
|
Smells like an stl issue.
You will get this type of message if you do something like this:
<br />
std::vector<long> vecLong;<br />
int n = vecLong.size();<br />
A lot of the stl classes returns a size_t numeric data type (instead of say, int, long etc).
Its not an error, but you should be aware of any overflow issues. If you are sure that your DWORD variable has enough range to accomodate the stl's size_t number, then just do a simple type cast.
<br />
std::vector<long> vecLong;<br />
int n = static_cast<int>(vecLong.size());<br />
I Dream of Absolute Zero
|
|
|
|
|
The compiler is telling you exactly what is wrong. Show the line of code in question.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
this is not an error. it is just a warning.
the compiler warns you about the fact that you copy some value of a particuliar type into a smaller type, hence the "possible loss of data".
what you can do to avoid this is :
- make the two types identical
- explicitely cast while assigning the value
- disable temporarily/totally the warning using the #pragma warning(disable:4267) statment...
|
|
|
|
|
toxcct wrote: - disable temporarily/totally the warning using the #pragma comment(disable:4267) statment...
I believe you meant #pragma warning(disable:4267).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: believe you meant #pragma warning(disable:4267).
yup, typo 
|
|
|
|
|
Are you compiling as 64-bit by chance? I believe size_t is a 64-bit integer on 64-bit platforms whereas DWORD (which is just an unsigned long) is always 32-bits. Thus, if you try to implicitly cast a size_t to a DWORD, it will give you that warning. To get around it, either ignore it, use bitshift operations to get the lower 32-bits, or use static_cast to explicitly cast it to a DWORD.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
