You must implement drag support on the source (TreeView) and drop support on the target (ListBox). With MFC this can be done using OLE Drag and Drop[^]. Tree Views have basic drag support and it seems that you already got it working. So you have to implement the drop support to your List Box. There are some articles here at CodeProject that might be helpful: http://www.codeproject.com/search.aspx?q=mfc+drag+drop&x=0&y=0&sbo=kw[^]
func(node* &h, int n, int m)
h is a INOUT parameter, if func changes h then the caller see the changed value (that is after function execution, h could point to another address).
func(node* h,int n, int m)
h is a IN parameter, if func changes it, the caller doesn't see the changed value.
CreateThread()
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
CPallini wrote:
Anyway, it is wrong calling delete on the memory allocated via CreateDIBSection.
Which might be the reason for the exception because _BLOCK_TYPE_IS_VALID is thrown when trying to delete memory that wasn't allocated using new.
Because left/right key combined with shift/ctrl key are used to mark grid cells, I have chose to use F7/F8 key for my needs. Thank you all of you for patience and attention. Bye.
Have alook at: "[34.12] Why can't I separate the definition of my templates class from it's declaration and put it inside a .cpp file?"[^] and also at [34.13] of the same document.
LVS_EX_HEADERDRAGDROP is a extended style, that is why should be setup not there, but using SetExtendedStyle method:
ListCtrl.SetExtendedStyle(LVS_EX_HEADERDRAGDROP);
I don't know Win32, but I am sure there is SetExtendedStyle Win32 function ...
Vaclav_Sal wrote:
Apparently compiler does not like to have both constructor and class variable names to be same
Not true, it does not matter. That is why you need to use the this pointer, so the compiler knows which variable you are referring to. Consider the following:
Class Foo
{
int var1;
foo(int var1)
{
var1 = var1; // referring only to the parameter var1
this->var1 = var1; // now it knows that the first one is the class variable.
}
None of which has any relevance to the issue you are describing. Forget about what goes on in the constructor, it is not connected to the probelm. You need to go back to the documentation and check carefully the definition of the TFT_LCD::LCD_Write_COM_DATA_t method.
If the parameters are actually constants, how about instantiating a template class?
int const PROCESSOR_COUNT = 42;
template scheduler
{
// constructors, other methods
private:
processor_data data[processor_count];
};
scheduler sched;
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
