|
how about writing a lil prog to reboot the machine and calling it from the service?
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
already tried that and I get the same result as before
|
|
|
|
|
|
I am sorry I am not answering your question infact I am stuck with one problem and I think you have the solution. I have develoed a chat server in VC6.0 now I want to run it as service and I have no idea how to do that I think you will be having some code because you have written that you are running C++ program which is already running as service can you please help me...?
Thanks in advance
Prateeti
|
|
|
|
|
I am using the windows 2000 resource kit have my program to run as a service. If you would give me your email address I will send you the commands along with instructions plus I will send you code telling you how you can do the same thing in c++ but the microsoft way is easier
|
|
|
|
|
I am making a self-updating console application
that downloads a new version of itself, launches
the new version via CreatProcess(), and then
immediatly quits. However, it seems that the old
version DOESN'T quit and both of them run at the
same time, in the same console window and create
problems. (the program is multi-threaded)
So I guess my question is -
Is there a better way to make a program self-upgrade
itself?
Thanks for your help!
|
|
|
|
|
Hello,
I load a bitmap and draw it on my dialog background.
I've a static box on the dialog too.
I used SetBkMode(TRANSPARENT) in OnCtlColor but it doesn't work
How can i do it ?
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
I am ALWAYS exploring and uncovering things in C++, and if by chance I believe I may have discovered something unusual, I revert to the various C++ textbooks for clarification and/or correction.
Here's an example of what I'm talking about: A publicly derived class ought to be able to access "protected" members of its base class. Well this sample exercise I did, doesn't seem to follow that rule.
This is what the compiler said, "error C2248: 'storename' : cannot access protected member declared in class 'Store'."
==============================================
class Store
{
etc.
protected:
string storename; // I should be able to access this member !!!!!!!
int storenum;
};
class Food : public Store
{
public:
Food(string na, int num, string foodItem, float retprice, int invAmt)
: Store(na, num)
{ etc. }
void Msg(string msg)
{
reinterpret_cast<<store*>>(this)->Msg("HQtrs"); // dbl angle brackets needed for msg
cout << '\n' << ((Store*)this)->storename << endl; // error here !!!!!!!
etc.
}
etc.
};
==============================
The reason I'm casting the 'this' pointer to Store is to qualify the data member to which I am referring.
But why is the compiler telling me that this publicly derived class cannot access the protected member of its base class?
Thanks for any help. I appreciate it.
William
|
|
|
|
|
A derived class can internally access the protected member. You're trying to access it from the global namespace.
What I mean is, an instance of Store could refer to storenum within one of its methods. But storenum isn't accessible outside the class. That would make all protected members essentially public!
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks Ravi.
I don't believe I'm accessing the class member from the global namespace. I am accessing it from within the definition of the derived class.
William
|
|
|
|
|
Did you mean to do void Food::Msg(string msg) instead of void Msg(string msg)? The way you have it, Msg() is declared in the global namespace.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks Ravi.
Because I am defining the function 'Msg()' inside the class definition, I don't need to qualify it with the class name and the scope resolution operator. Therefore, the definition of 'Msg()' is correct.
There is also another function named, 'Msg()' defined in the base class 'Store' (which I did not show), which is why I chose to use the 'reinterpret_cast' cast operator to access that specific 'Msg()' function in 'Store'. But that's NOT where the problem is happening. That line gets executed fine, and everything gets done that is supposed to get done in that line. Everything is OK with that line!!!
The problem is with the next line following it, where I'm accessing a protected data member of the base class. That's where the problem is occurring.
Now, according to the rules of C++, a publicly derived class is allowed to access protected data members of its base class, but the compiler is not agreeing, and that's the line where the disagreement is pointing to.
William
|
|
|
|
|
public derivation:
- public members (of base class) are made public
- protected members are made protected
- private members are not accessible
protected derivation:
- public members are made protected
- protected members are made protected
- private members are not accessible
private derivation:
- public members are made private
- protected members are made private
- private members are not accessible
I hope this answers it. You were trying to access a protected member as if it were public.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
"A member of a derived class can use the public and protected members of its base class as if they were declared in the derived class itself."
The C++ Programming Language (page 305)
Bjarne Stroustrup
William
|
|
|
|
|
 Oops, I went back to look at your poorly formatted sample and realized that Msg() is a member of the Food class. That explains why you're confused about the compiler error.
WREY wrote:
The reason I'm casting the 'this' pointer to Store is to qualify the data member to which I am referring.
You don't need to that in this case, since you don't have a storename in the Food class. If you did, the proper way to qualify it is via the scope-resolution operator: Store::storeName.
Still, I don't really understand why the compiler doesn't account for the scope of the variable when the cast is made. It may just be a compiler bug.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
I am one of those people who ranks neatness and readability high on his list when writing code. I do NOT believe in sloppiness and poorly formatted code. You saw poorly formatted code because that's what CodeProject showed, but that's NOT the way it appears when looking at my code.
Also, I try to limit only those portions of the sample code that are relevant, which means a lot of times you will see, "etc." for parts that are missing and are not relevant.
You suggestion is a good one (which does work), but I could have used just "storename", (and not "Store::storename" as you have shown), and it would have worked just fine also.
In this exercise, I PURPOSELY want to use the 'this' pointer; I PURPOSELY want to qualify the 'this' pointer with the class name whose object it is supposed to be pointing to, and then by way of such a pointer, have it access a protected data member of the base class from the derived class.
Two things I'm trying to accomplish in this exercise:
1) Access protected members of the base class by way of the 'this' pointer (which means qualifying it).
2) Specifically pick which member(s) of either class (base or derived) I might want to access (if by chance BOTH classes have members with the SAME name) ultimately providing me with a way I might be able to transcribe the code using templates.
William
|
|
|
|
|
WREY wrote:
I am one of those people who ranks neatness and readability high on his list when writing code. I do NOT believe in sloppiness and poorly formatted code. You saw poorly formatted code because that's what CodeProject showed, but that's NOT the way it appears when looking at my code.
Relax William. I was commenting on the fact that it was poorly formatted here. And as a matter of fact, it's not just CP's fault, because you could have used the pre tags around the code to help keep it well formatted. I'm sure you understand that it could have made a significant difference to those reading your post.
At any rate, it's good to hear about yet another developer who cares about neatness and readibility. My experience has been that we're a rare breed.
WREY wrote:
You suggestion is a good one (which does work), but I could have used just "storename", (and not "Store::storename" as you have shown), and it would have worked just fine also.
In this exercise, I PURPOSELY want to use the 'this' pointer; I PURPOSELY want to qualify the 'this' pointer with the class name whose object it is supposed to be pointing to, and then by way of such a pointer, have it access a protected data member of the base class from the derived class.
Yes, I realized that it was basically just an exercise. I just wanted to make sure you knew the proper way to distinguish between variables of the same name across derived classes.
WREY wrote:
1) Access protected members of the base class by way of the 'this' pointer (which means qualifying it).
I see, so you wanted to use this as an obvious way to say, "storename is a member of this class", sort of like what the m_ prefix does for the MFC classes.
WREY wrote:
2) Specifically pick which member(s) of either class (base or derived) I might want to access (if by chance BOTH classes have members with the SAME name) ultimately providing me with a way I might be able to transcribe the code using templates.
Again, the scope resolution operator is the way to go, which you can also use with "this": this->Store::storename;
I think Chris may have hit upon the actual reason why the compiler does not like what you're trying to do. And I must confess that I also thought of it myself, but just wasn't sure. I thought there was a possibility of it being a compiler bug; perhaps one only found in VC6.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Thanks for your reply.
I believe you have provided me with what I was looking for (at least for the time being); the use of "this->storename" from the derived class. (Again, I don't need to qualify the data member with its class name. That would only be necessary if ambiguity becomes an issue.)
William
|
|
|
|
|
It's not working because to the compiler, what you are trying to do is equivalent to this:
class Base
{
protected:
int x;
};
class Derived : public Base
{
public:
void Function()
{
Base b;
b.x = 10;
}
};
Obviously this is incorrect. And, when you tell the compiler that "this" is a "Store" pointer by casting it, you are doing the exact same thing I just showed in this example. Now, if you want to "qualify" the class to which you are referring, to remove an ambiguity, as in the following example, you should use the scope resolution operator.
class Base
{
protected:
int x;
};
class DerivedBase : public Base
{
protected:
double x;
};
class Derived2 : public DerivedBase
{
public:
void Function()
{
Base::x = 10;
DerivedBase::x = 10.0;
}
};
Maybe I'm wrong, but this is how it seems to me...
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Thanks for your reply.
I can see your point for needing the class name and the scope resolution operator. It's needed because there are two data members with the SAME name in two different classes, and the only way you can avoid ambiguity in that situation is by specifically qualifying each data member with their respective class name followed by the scope resolution operator.
That is NOT the case in my example. In my sample, only the base class has that particular data member name (there's no ambiguity present). Moreover, the base class is instantiated through the derived class constructor initializer list.
The thing is, I can use just the protected data member name by itself (from a derived class function, even without the base class name and scope resolution operator) and it would be correct!! But if I were to try and access the base class by way of its own 'this' pointer (and qualify it as the base class through casting), suddenly, the compiler starts complaining if I were to try and access a protected member of the base class.
This is where I am. The compiler obviously isn't happy, and it's complaining. I need to know what is there in the rules of C++ that's causing the compiler to report a syntactical error (other than what it's already saying), when another part of the rule is definitely saying differently.
I don't see where I'm violating anything by using the base class 'this' pointer to access one of its protected data member from a derived class.
Maybe I'm suffering from tunnel vision here, but this is the kind of stuff that makes C++ so interesting (or frustrating)!!
William
|
|
|
|
|
The first example illustrates why you can't access the protected base member. The second example was only illustrating the way to avoid ambiguities you had discussed with Alvaro Mendez. Let me see if I can show a better example of why the compiler is complaining.
class Base
{
protected:
int x;
};
class Derived : public Base
{
public:
void Function()
{
Base * pBase = new Base;
pBase->x = 10;
delete pBase;
pBase = (Base*)this;
pBase->x = 10;
}
};
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Cool!!! Your explanation makes a lot of sense.
Thanks for your reply!
William
|
|
|
|
|
hello,
I've noticed that when I set a bitmap on a CStatic the previous bitmap don't get destroyed, then I would like to know how to delete the previous image from memory.
Thank you in advance.
NOTE:
Please don't laugh too much while answering...
|
|
|
|
|
::DeleteObject will delete any GDI object such as a HPen or HBitmap. If you're using MFC and the bitmap is in a CBitmap, then it's going to be deleted for you.
Joan Murt wrote:
Please don't laugh too much while answering...
I'm not laughing - I might laugh if you ask this again and again over the next few months, as that would indicate an inability to learn. But every single API, every single keyword, every single bit of knowledge we have, someone had to show us, either indirectly through a web site or book, or directly as I am now. There is no shame in wanting to learn, there is shame in not being willing to be told.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
