When you have two mice, Windows doesn't give you two mouse pointers. It merely moves the single mouse pointer in response to whichever mouse moved. Therefore it gives no way to tell which mouse was moved.
DoEvents: Generating unexpected recursion since 1991
I will take a look. In fact, I also am using two touch screen monitors, but I did not want to comlicate the question. As you know, the touch screen activity is reported as WM_MouseWhatever messages. So any additionl info you can give me to point me in the right direction would be great.
In my implementation 'AClass' initiates a large amount of data whilst potentially undertaking a fairly complex procedure. The entire procedure can be optimised very easily when a non-constant version of the object is supplied:
However, this leads to a different problem because the 'const' keyword is no longer used. There are places within my application which must parse such objects as 'const'. So the natural solution would seem the following:
Sadly the above produces the following warning message:
'warning C4521: 'AClass' : multiple copy constructors specified'
I know there are workarounds which involve 'const_cast', but in my application the two copy constructors need to behave differently. Also, it isn't appropriate to use pointers and references to avoid this issue because it would cause serious maintenance issues and would be too confusing.
Just to expand a little further...when I execute the program the correct constructor is in fact called based upon const-ness. But what I need is confirmation that this is correct well-formed C++ and that it will compile correctly on other compilers. As this is only a warning (as opposed to an error) I just want to make sure that what I am attempting is not somehow dangerous or insecure.
If it isn't dangerous (or insecure) I will just use:
Without knowing how the optomization works, I am limited. If the non-const copy constructor doesn't change the source in any significant way, you might be able to declare certain members mutable. If the copy constructor destroys the source object, you might want to implement it as a swap function. In either case, I can imagine special cases that would require alternative methods.
I don't know what you are trying to achieve, but even if you were to manage to have two different copy constructors now, I think you would be laying a maintenance minefield. Reading your code it is not easy to understand which version will be invoked and what happens. Seeing
gives no clue that b is modified. You, or others, may not recall this when maintaining the code.
If possible, implement the const copy constructor that uses a const object.
Think of a good descriptive name to call the non-const version, and do a two-step construction, if necessary creating a separate constructor to create an empty or invalid object, e.g.
AClass a;<br />
If these are always created on the heap you could make a simple helper function to do the work
AClass* pA = CreateNewClassAndModify(b);
I'm sure there are other ways.
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
(also posted on the dundas forum)
I'm using the Dundas grid to display a simple grid.
In one of the cell, I use the Ellipsis Cell type, it's a cell type with a "..." button to call up a dialog.
When I click on the "..." button my dialog is called, but it's not "modal", the grid still has focus and I can click the button again and again. seems the dialog message loop is overridden for at least one message, if I click on the dialog, the dialog really become modal.
This code is copied from the cell type Dundas sample. ( and I tried the same thing with the dundas demo to see if the problem is in my code )
It's a small problem, but it's bugging and I'm not certain why the DoModal does really eat the messages, and there's one message that get handled by the underlying grid.
Solution : There was SetCapture that was not supposed to be there. I removed it, tested all relevant code and behaviour and now everything is ok; no need to disable parent window or do other things, DoModal works as is should.
Modal dialogs in MFC are not really modal, and I believe that this allows for better message handling in the MFC framework. Modal dialogs just disable their parent to simulate a modal dialog.
You should be able to manually disable the dialog's parent to get around this problem.
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
pView->whatever() causes ASSERT as defined in wincore.cpp - void CWnd::AssertValid()
CDocument::OnCommand - selected some operation from menu
CView *pView = get active view
call DLL (pView, p2, p3, ...)
put up dialog
move slider, now need to update pView in main app
callback(pView, p2, p3 ...)
No matter if I pass a ptr to CDocument or CView the callback will fail (ASSERT) someplace
If I pass in the HWND and in the callback use CWnd::FromHandle() and then call InvalidateRect() I can get thinks to redraw but I want to access items in the Doc or View.
The ASSERT code states
// Note: if either of the above asserts fire and you are
// writing a multithreaded application, it is likely that
// you have passed a C++ object from one thread to another
// and have used that object in a way that was not intended.
// (only simple inline wrapper functions should be used)
// In general, CWnd objects should be passed by HWND from
// one thread to another. The receiving thread can wrap
// the HWND with a CWnd object by using CWnd::FromHandle.
// It is dangerous to pass C++ objects from one thread to
// another, unless the objects are designed to be used in
// such a manner.
So does anyone have a way around this?
Thanks in advance
Gerber Scientific Products
Senior Software Engineer
Phone: 860 648 8151
Fax: 860 648 8214
83 Gerber Road West
South Windsor, CT 06074