|
this is the current object instance.
you can do stuff like that...
class CClass
{
int i;
void Method();
}
void CClass::Method()
{
this->i = 1;
i = 1;
}
or if you you want to pass yourself to another class or method :
...
CPaintDC dc(this);
...
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
"this" is introduced so the compiler could make the difference between members of the class and members of another object.
eg. if you would do this:
<br />
public void SetSomeInt(int input){<br />
input = input;<br />
}<br />
then the compiler probably would complain. which one is the parameter and which one is the variable of the class?
if you do this:
<br />
public void SetSomeInt(int input){<br />
this->input = input;<br />
}<br />
it will probably work.
It's just a pointer to the Object itself.
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
"this" is introduced so the compiler could make the difference between members of the class and members of another object.
eg. if you would do this:
<br />
public void SetSomeInt(int input){<br />
input = input;<br />
}<br />
then the compiler probably would complain. which one is the parameter and which one is the variable of the class?
if you do this:
<br />
public void SetSomeInt(int input){<br />
this->input = input;<br />
}<br />
it will probably work.
It's just a pointer to the Object itself. (and that's the reason why you can't use it in static functions)
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
I would advise that you *DO NOT* use the same naming convention for local function variables and member variables. It can, and will, always lead to confusion and mistakes.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Quite true.
Just to have no misunderstandings : "I do not do that"  , but the example just explains nicely what 'this' means.
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
Antony M Kancidrowski wrote:
I would advise that you *DO NOT* use the same naming convention for local function variables and member variables. It can, and will, always lead to confusion and mistakes.
That's why they invented m_ 
Michael
CP Blog [^]
|
|
|
|
|
you've been having many good answers, so i won't add more about the this pointer you're asking for.
i'd just like to tell you that this is an important part of the C++ language, and you'd so better get a reference of the language to learn about it...
there are many books on the subject, and also the MSDN treats about it.
cheers,![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
TOXCCT >>> GEII power
|
|
|
|
|
If I use GetSysColour to get a system RGB value, then create a brush using that value and then draw a rectangle, the colour of the rectangle is different?
I'm puzzled by this, under 2000 you can see this all over the place, i.e menu bars. If you get the system colour then you get back the value C3C3C3, if you paint to the screen with this colour you get C6C3C3, you can verify this by reading back the pixel.
I've only noticed this because I'm implementing a VS.NET style gui and I couldn't figure out the luminance values, once I'd realised that the colours are actually different to what you request it all fell into place.
Adrian
|
|
|
|
|
Hi,
i'm using MS Visual C++ .Net and i have a problem with odbc and mfc. It occurs sometimes while running the release application *.exe - but never(!!) while running the programm under Visual in debug mode (no compiling error).
An "unhandled win32 exception" is thrown.
Debugging the *.exe shows line 624 in dbrfx.cpp, (function: void RFX_Text(...)). A message like: "cannot read in memory" comes up.
The exception is thrown while some database actions. I first do a select in table... (by CRecordset) and then i'm trying to do an update in the same table (also by CRecordset). RFX_Text is updated and sometimes: *pow*.
Does anyone have some helpful idea? I tried to do my update by CDatabase::ExecuteCommand(...) but everything is the
same...
Thanx
Jo
|
|
|
|
|
Are you using more than one thread to connect to the database in your application? If so DAO is not multithreaded and will lead to many problems.
John
|
|
|
|
|
Thanx for you reply.
I'm not using DAO, i take odbc.
Yes, my db operation runs in a separate thread. But thats not the problem. The error also occurs, while running sequential without thread.
|
|
|
|
|
Its ok to use a database in a thread as long as you don't try to use it (CRecordset) in more than one thread.
John
|
|
|
|
|
I've also found that CRecordset is prone to memory leaks so I started using ADO instead which I find to be a lot simpler. (which is what a simple mind like mine needs)
[insert witty comment here]
bdiamond 
|
|
|
|
|
John: Its ok to use a database in a thread as long as you don't try to use it (CRecordset) in more than one thread.
Yes, I also think so. The problem is CRecordset. But - in my case - it does not depend on using it in more than one thread. I first created a CRecordset and did some SELECT statements, after that i used CDatabase (or another CRecordset) for the insertion of records. And thats it: the first CRecordset is bound to the database and the insertion by other instances causes the error. So, now i'm using only one CRecordset and everything works well .
bdiamond: I started using ADO instead which I find to be a lot simpler
OK, that's good to know  . I'll remember that in next projects.
|
|
|
|
|
Hi
I have a vc++ application, which i would like to distribute as evaluation copy. The application should not run if the specified 30 days is over.
It should handle system time changes etc.
Could anyone help me out !
Thanks and regards
The Best Relligion is Science.
Once you understand it, you will know God.
|
|
|
|
|
The best way to distribute an evaluation copy is to limit it's functionality. That is, comment out sections of code that offer functionality you do not want to provide in a trial version. Then build a trial version.
Another alternative is to limit the amount of executions. This can be handled by keeping a record of the execution times inside the executable itself, which makes it more difficult to hack. Using time periods is always difficult, because changing the BIOS date will mix up any period counters, and there's no way you can detect it, if done correctly.
So, when you hand out evaluation copies, cripple them. This allows your testers to evaluate the product, but they can't hack it (as there's nothing to gain), and if they feel like purchasing the full version, you can sell it to them.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hi
Thankyou for your time.
I have a specific requirement for 30 day trial versions that is the main concern.
I just want to know the trick behind creating the 30 day trial versions.
Thanks & Regards
The Best Relligion is Science.
Once you understand it, you will know God.
|
|
|
|
|
I just want to know the trick behind creating the 30 day trial versions.
Either write a hidden file or registry key that contains a data that you program checks at startup or roll out an encrypted code that the user is emailed that contains the date that the program quits working.
John
|
|
|
|
|
Hi
Thankyou very much.
I will be back after trying out some trials 
Regards
The Best Relligion is Science.
Once you understand it, you will know God.
|
|
|
|
|
You have to remember that if you put full functionality in your trial code hackers will try to find a way around your protection routines so try to put multiple checks (of the expiration date and possibly a crc check of the executable) in your program to make it difficult to crack.
John
|
|
|
|
|
My suggestiion is to set a registry key in a place known only by you or in several places in registry.
Your program should have for example 50 hours when it can be avalaible.
In registry you set at first the value 50
And when your program starts you shoul set a timer
SetTimer(NULL,NULL,50*60000,TimerProc);
and when the time elapses the TimerProc should change the registry key to EXPIRED or something like this.
The program should always start by reading this key and if it is expired close and if it is not set the timer.
This should work
gabby
|
|
|
|
|
Hi
thank you all,
This will work fine if you limit the trial version by the number of hours.
I want to limit the application the by number of days. Say If he is not using the application for 5 days after installing, his trial period should count that also..
I know there is always a crack for that..it is impossible to build a crack proof system, but what I want is somewhat difficult algorithm
Thanks and regards
The Best Relligion is Science.
Once you understand it, you will know God.
|
|
|
|
|
Can anyone tell me why what seems like a simple cast fails to compile in one case, but passes when the code is rearranged.
Let me show you what I mean.
IA and IB are my own COM interfaces with one method taking the other as a parameter.
This fails:
<font color=green>
IAPtr PB = NULL;
IBPtr pA = NULL;
<font color=green>
..
pB->SomeMethod(&pA); <font color=green>
I get the error message:
General.cpp(319) : error C2664: 'MyLibrary::IA::SomeMethod' : cannot convert parameter 1 from '_com_ptr_t<_IIID>::Interface ** ' to 'IUnknown ** '
But This works:
<font color=green>
IAPtr pB = NULL;
IBPtr pA = NULL;
IUnknown* pUnk = NULL;
<font color=green>
..
pUnk = static_cast<IUnknown*>(pA)
pB->SomeMethod(&pUnk);
Surely these equate to the same thing? 
I Dream of Absolute Zero
|
|
|
|
|
Actually, they don't.
The pointer pA points to a pointer to the interface class IA, which, according to COM rules, inherits from IUnknown, either directly or indirectly. However, it looks like you use the COM helper classes to declare IAPtr and IBPtr. When you do this, they can no longer be directly cast, but require explicit casting. To skip using COM helper classes, define the pointers in the following manner:
typedef IAPtr IA* After this, you can no longer directly use them, but must instantate and initialize them manually. The prize is that they support direct casting.
The method you describe assumes a pointer to the IUnknown interface pointer. What you're passing it is a pointer to a pointer to IA. These two are not automatically compatible.
Using the following call would solve the case without extra work:
pB->SomeMethod( &(reinterpret_cast<IUnknown*>(pA)) ); -Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thanks for that explanation.
Can't say I fully understand, but when it comes to COM, who does?
I do get the general jist though.
Antti Keskinen wrote:
Using the following call would solve the case without extra work:pB->SomeMethod( &(reinterpret_cast<iunknown*>(pA)) );
I had tried something similiar :
pB->SomeMethod(reinterpret_cast<IUnknown**>(&pA));
But that didn't compile, so I gave up on that train of thought
Thanks again.
I Dream of Absolute Zero
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
