|
LINK : warning LNK4075: ignoring /EDITANDCONTINUE due to /DRIVER specification
Thanks 
|
|
|
|
|
Open project properties. In C/C++ section, change "Debug Information Format" to "Program Database."
In Link section, you may also want (need?) to change "Enable Incremental Linking" to "No"
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Its just a conflict between some of the complier flags you have. Nothing serious. I'm not too sure what the /DRIVER settings does, but the /EDITANDCONTINUE allows you to modify code while you're debugging.
I used to know where these settins were in the project options, but I cant seem to find them anymore. Sorry
|
|
|
|
|
Hi,
I have a problem regarding the message handling of Control Bar. I have a Control bar which is derived from CControlBar. This control bar has a Tree control inside it. The problem is that, iam not able to capture the changes in the tree item (selection cahnges). I used the like this:
I used this inside.... BEGIN_MESSAGE_MAP
ON_NOTIFY(TVN_SELCHANGING, 123, OnSelchangedTreectrl)
END_MESSAGE_MAP()
But whenever i chnange the selection inside my tree, there is no notification. But there is a notification for the context menu, which i used as:
ON_WM_CONTEXTMENU()
This contest menu message gets captured properly, but not the tree control changes.
Can anybody please help me in understanding this. i would be very much grateful, if someone can direct me to some code, which uses something like the one i have stated.
Thanks a lot in advance
thx,
KAB
|
|
|
|
|
Hello,
Sorry if this is a completely lame question, but is there a approach that allows info to be securely sent server->client->server such that only the client application, and no other application on the client's side, can intercept it? This would be useful in situations where the client application only wants certain parts of the incomming data to be available to the client's user, and can not assume the client is not peeking (monitoring incoming traffic).
Thanks,
KnaveWave
Oi! Oi! Oi!
|
|
|
|
|
What about encrypted data?
|
|
|
|
|
Couldnt an evil app on the client's side simply obtain the key and decrypt as well?
|
|
|
|
|
You don't HAVE to keep the key in a readable state in the client. You can do a simple encryption of the key within the client. (XOR, bit shift or some other way).
Then decrypt the key whenever you need it. When there is no need for the key, overwrite the used key buffer with random characters, and delete it.
That way, the key will exist in plain text for a very short amount of time.
Just a thought, maybe you can decode the key witin a CriticalSection block?
Will a CriticalSection stop other apps from executing? I'm not sure.
|
|
|
|
|
Go for Digital Certificate
never say die
|
|
|
|
|
Regarding your user name:
Any connection to "Knaverlisa" ?
|
|
|
|
|
Hi all,
I would like to know how do I destroy the IDispatch pointer if I have used it in my code.
Can I do something like LPDISPATCH lpRai = NULL ; Will this destroy the pointer and the value whose address it is holding? How do I destroy the value so that no memory leaks happen?
Also supposing I declare a class like CMyClass myClass ; does myClass = NULL destroy the variable?
Thanks for all your time.
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
Save My Soul - (SMS) wrote: I would like to know how do I destroy the IDispatch pointer if I have used it in my code.
Calling Release().
Save My Soul - (SMS) wrote: Also supposing I declare a class like CMyClass myClass ; does myClass = NULL destroy the variable?
No. You don't have to do anything. When it goes out of scope it will be destroyed.
But if you use new then you have to call delete to kill it.
Nibu thomas
Software Developer
|
|
|
|
|
Thanks a lot for your answers, Nibu.
Nibu thomas wrote: No. You don't have to do anything. When it goes out of scope it will be destroyed.
I guess class whose object is being created must handle all its variables' destruction itself in its destructor?
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
Save My Soul - (SMS) wrote: I guess class whose object is being created must handle all its variables' destruction itself in its destructor?
Yes. We destroy only those objects in the destructor that are dynamically allocated.
Nibu thomas
Software Developer
|
|
|
|
|
I have just one more question.
Lets say that I have used LPDISPATCH lpTemp. Then I pass this lpTemp as an argument to another function. Now what goes on behind the scenes when this happens? Is the AddRef of lpTemp called? How do I handle this scenario? Also is lpTemp->Release() enough to free up the used memory or do I have to use delete lpTemp to free the memory?
Thanks.
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
Save My Soul - (SMS) wrote: Then I pass this lpTemp as an argument to another function.
Call AddRef()
Save My Soul - (SMS) wrote: Now what goes on behind the scenes when this happens? Is the AddRef of lpTemp called? How do I handle this scenario
Nope you have to call it. What AddRef does is it simply increases the reference count of an object. So that whenever a corresponding Release is called it doesn't accidently delete the object. Because Release always checks for the reference count.
Release will only delete an object if the reference count is zero, this means there are no more references to that object and it is safe is to delete it.
Save My Soul - (SMS) wrote: Also is lpTemp->Release() enough to free up the used memory
Yes, provided you have judiciously used it along with AddRef.
Save My Soul - (SMS) wrote: do I have to use delete lpTemp
Never do that.
Nibu thomas
Software Developer
|
|
|
|
|
Thanks a mil... 
Can you direct me to some COM tutorials, where I can learn all these stuff?
Thanks once again..
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
Save My Soul - (SMS) wrote: Can you direct me to some COM tutorials, where I can learn all these stuff?
Sure, Michael dunn's[^] your teacher.
He has got other articles on COM which is in series format. Like COM Part I, Part II, etc. Go through them one by one.
Nibu thomas
Software Developer
|
|
|
|
|
Nibu thomas wrote: Call AddRef()
Okay lets say I have a function with the below definition:
bool hello( LPDISPATCH lptmp1, LPDISPATCH &lptmp2 )
The first argument gives a value and the second argument returns a Long IDispatch Pointer. So for this implementation, where should the Addref for lptmp1 and lptmp2 occur. Should it be inside this function like
bool hello( LPDISPATCH lptmp1, LPDISPATCH &lptmp2 )
{
lptmp1->AddRef() ;
lptmp2->AddRef() ;
}
Or should it be AddReffed before calling the above function?
Thanks for helping me out.
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
Save My Soul - (SMS) wrote: The first argument gives a value and the second argument returns a Long IDispatch Pointer. So for this implementation, where should the Addref for lptmp1 and lptmp2 occur. Should it be inside this function like
bool hello( LPDISPATCH lptmp1, LPDISPATCH &lptmp2 )
{
lptmp1->AddRef() ;
lptmp2->AddRef() ;
}
Good question....
For lptmp1 it could be inside hello because the use of lptmp1 finishes here in hello and for lptmp2 it could be outside hello because it continues to exist beyond hello. Because I believe AddRef and Release should take place in the same scope.
Nibu thomas
Software Developer
|
|
|
|
|
Hi,
I am using the MSXML API for xml processing. Suppose I declare a
IXMLDOMElementPtr spRootElem ;
pointer. Do I have to AddRef this and Release it after I have finished? Do I have to do something like
IXMLDOMElementPtr spRootElem ;<br />
spRootElem->AddRef() ;<br />
...<br />
spRootElem->Release() ;
Please Advise.
Thanks.
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
Yes of course. All COM object works likewise. Go through the tutorial that I suggested.
Nibu thomas
Software Developer
|
|
|
|
|
COM objects use reference counting. When you make a copy of an interface pointer you call AddRef to increment the reference count and when you're getting rid of one you call Release to decrement it. When an object's reference count transitions to zero it does whatever needs to be done to clean up house. In C++ code this is typically a delete this; or some such.
Steve
|
|
|
|
|
I have just one more question.
Lets say that I have used LPDISPATCH lpTemp. Then I pass this lpTemp as an argument to another function. Now what goes on behind the scenes when this happens? Is the AddRef of lpTemp called? How do I handle this scenario? Also is lpTemp->Release() enough to free up the used memory or do I have to use delete lpTemp to free the memory?
Thanks.
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
If the other function makes a copy of lpTemp, say for later use, it will call AddRef through it. When it doesn’t need the copy anymore it will call Release. What, if anything, has to be done to free the storage occupied by the pointer itself depends on where it's stored. If it's a local variable (as is typical) nothing has to be done as locals variables take care of themselves. Same for a global. If it's a member variable it depends on the storage used by the object - if it's local or global again no action needs to be takes. The exception in all of this is for heap allocated objects. If a variable in on the heap you have to free it. The rule is simple, if you new something remember to delete it.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
