|
CPallini wrote: Thank you, following the link I got the today's CP memorable quote
Glad to be of service.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Usually functions are declared that way to be certain that an existing object is provided, because otherwise it would not serve any point of calling the function. Compare with the copy constructor.
If you feel you should call that function without a valid object to pass as reference, you have either misunderstood what the function does or the one who declared it didn't understand the concept of references.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Please see my above reply so you understand the scenario I am with.
Thank you.
|
|
|
|
|
Well, when I saw PJ's reply I became unsure whether you actually have a variable but wasn't familiar with the concept of references, or you don't have an object at all.
The small novel in your reply to PJ is hard to understand. It would be easier to understand it if you showed the declarations of the functions.
However, my first reply still stands: either you're using the API the wrong way, or the API is poorly designed. It doesn't matter how obscure the description is of how you are going about it.
Are you sure the class with the private constructor is not implemented as a singleton? When I implement singletons I usually protect the constructors and have a static declared member function such as GetInstance() that would create the object if it hasn't been created earlier, but hand out a pointer to it if the object already exists.
If this is the case you could get hold of the one and only object there is to pass and as I understand your description that would solve your problem.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
i tried to make it more clear in the last message, ie the unclear novel I recited.
there were neither a getinstance internal methode neither a createinstance inside a helper class factory.
Thank you anyway.(note the solution i was given : it fools the compiler and it was just what i wanted).
|
|
|
|
|
hINTModuleState wrote: note the solution i was given : it fools the compiler and it was just what i wanted
Mmmm, I saw the "solution" and I thought "this is exactly why it's been said about C++ that it's harder to shoot yourself in the foot than in C, but when you do it blows your whole leg off".
At the best, the API is poorly designed and this will actually work, which means that the programmer that designed the API didn't really know how to use references and their purpose.
At the worst, it seems to work, but it will crash later after you've distributed the application under obscure circumstances. Then you'll have an angry customer, or several, that requires an immediate fix and you have no idea of how to solve it.
Either way you will end up with a solution that you cannot really rely on and it will be "proven by use". 
Best of luck! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
the things you are saying are not to be questioned. They are full of logic.
Actually the API is well designed. It uses all sorts of OO things and others,etc well in place : const, reference types,public, protected..
As I tried to explain in the bottom replay (the one I replied to myself) the case I am with and the context where I am trying to shout myself in the foot is just a case where I want to ensure a part of code to be well designed, compact and easy to improve. The leg wo'nt be blown off hopefully.
|
|
|
|
|
Do you mean to pass an invalid reference, like passing a NULL pointer? That can cause the program to crash and I can't imagine why you would want to do that. If that's what you want to do, then you can pass a dereferenced NULL pointer. But if the function tries to use that variable it will crash.
void foo(vartype& a);
vartype* ptr = NULL;
foo(*ptr);
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
Thank you so much.
modified on Thursday, November 20, 2008 4:15 AM
|
|
|
|
|
The callback which accepts a reference is :
void CClassB::OnProcessThisThing(T &t,..other params)
{
}
It is not but an override of a virtual function declared in the base class fromwhich the class
CClassB is deriving :
class CClassA {
protected :
virtual void OnProcessThisThing(T &t,..other params);
};
CClassA resides in an external library, an external lcode.(I only got the .h : so I cannot change it).
class CClassB :public CClassA.
CClassB is in my own code which depends on the above thirdparty library.
.
From within CClassB::OnProcessThisThing() I have to deal with an execution case that is triggered
asynchronously. (The external library code, triggers the virtual function in the base class, then
my override method gets focus.).
The reaction code to put in CClassB::OnProcessThisThing is complex.
Adds to that the fact that I have a very other scenario where I would need to execute the same
same reactionn code. Why would I have to make a copy and paste (two separate functions)
if I can merge the two things. Moreover
the two scenarios are coupled : the processing done in reaction to the first scenario
whereby the external code triggers the function, affects the very data and information received by it
when it is triggered internally following the second scenario. Hence merge the two things in a same bloc code
helps me tackle that interaction and easily understand my code.
Now the problem I encountered is how to call that function internally if it has that reference type
parameter.
That is what it was about.
|
|
|
|
|
In the above scenario, composition is better than inheritance.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I'm afraid I didnot understand M.Pallini.
|
|
|
|
|
Instead of inherit from ClassA, your ClassB should have an instance of ClassA as its own member, and delegate to such a member the shared functionality.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
modified on Thursday, November 20, 2008 6:05 AM
|
|
|
|
|
I see.
Anyway I have now metamorphozed the whole thing and no more need to fool the compiler.
Just to shif the discussion subject, do you rememeber that class XXX and class XXXImpl case ?
I just found an interesting use case in Poco C++ library wheer the XXX class delegates all work to the XXXImpl that is relevant to the target implementation plateform. (XXXImpl for Win32, XXXImp for Unix,etc).
Anyway just a flashback to something we talked about.
|
|
|
|
|
hINTModuleState wrote: I just found an interesting use case in Poco C++ library wheer the XXX class delegates all work to the XXXImpl that is relevant to the target implementation plateform. (XXXImpl for Win32, XXXImp for Unix,etc).
It's a real life example of the Bridge Design Pattern [^], I suppose.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi there,
Can someone please help me. I am programming a dialog GUI for a touch screen interface to control a motor and I want it to run the motor when someone presses the button and holds it and then the motor is stopped when it button is released.
Can I use BN_PUSHED and BN_UNPUSHED? or is there another way.
Does anyone have any examples that I could reference?
Cheers
Jim
|
|
|
|
|
BN_PUSHED and BN_UNPUSHED are old 16bit windows notifications used for drawing owner drawn buttons. Do not use them.
You should be be handling the WM_LBUTTONDOWN and WM_LBUTTONUP messages (or what ever the touch screen equivalent is) that are sent to your button control.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
|
Thanks for the help.
That's all running now.
Jim
|
|
|
|
|
I have the merge modules that Microsoft put out for the VC++ 2003 Redistributables but since VS2003 SP1 came out, I have not seen any new merge modules for VC++ 2003.
Does anyone know if the files in the redistribution merge modules would even get affected by SP1?
I dug around a bit and the MFC dll's didn't seem to get updated but I've not really done an exhaustive search. Can we still use the original redistribution dll's for VC++ 2003?
***********************
Update: I started to build a custom msm and Visual Studio directed me to where the merge modules are located when I tried to compile it???
(assuming a default installation path)
C:\Program Files\Common Files\Merge Modules
Call me slow, but I was searching for them from the root of my Visual Studio Directory. Sure, NOW I find it in MSDN. 
Someone just shoot me before I reproduce.
modified on Wednesday, November 19, 2008 2:10 PM
|
|
|
|
|
Oops, I take that back, the dll's did get updated after all. I'm just blind.
I'm guessing I just piece together my own merge modules with the updated dll's in my system directory. Any comments still welcome as I'm hoping these .msm files are neatly tucked away somewhere and I'm just not finding them.
thanks in advance.
modified on Wednesday, November 19, 2008 2:19 PM
|
|
|
|
|
Hello,
I wasn't sure if I should post this here or on the vista forum..
I have an MFC application that I would like to install on Vista in the normal C:\Program files\My App, it is also possible that my application updates certain files using a web update program that updates/writes to the executable directory as well. In vista, only Admins, syatems...can do that, How can i make all users be able to write to program files\My App ?
I know installer programs can write to C:\program files with no problem, I was curious to how does vista know it is an installer and it allows it to write but prevents non-installers from writing, the I reason was wondering may be it is like a registry key or varibale that i can read and I will be able to set it somehow to make my update program write to the program files too? I really don't want to change this to C:\users because its not a per user thing....
Does any one know or have an experience of how to go around or beat this vista permission issue?
Thanks
|
|
|
|
|
Add a security section to your application manifest file. This will effectively turn off UAC for the application (If UAC is on) and it will prevent virtualization for the Registry and File sections that the user does not have rights to.
That brings up topic number 2. The user will still need to have an Admin token to write to Program Files directory, HKLM, HKCR, etc as they always have on NT class machines. You can set up the security manifest to use "AsInvoker" but this will simply fail when they don't have an admin token. Use "requireAdministrator" for admin utility programs that require administrator access to the machine. This will prompt the user for admin credentials when they try to use the app if they don't already have an admin token. (and it'll put that cool little shield on your icon) 
Windows Vista Application Development Requirements for User Account Control Compatibility[^]
|
|
|
|
|
Thanks,
Can I find the information you sent in the link, if not, do you have a sample manifest or a link that can help me write such a manifest?
Thanks again
|
|
|
|
|
If you have VC++ 2003 or above (I think 2002 as well but not sure) you will get a manifest file created for your app if you create an MFC doc/view and basically choose the defaults. If you are adapting this manifest to a VC++ 6.0 application, you will need to adjust the contents as needed since the internal name needs to match the app I believe.
It's pretty straightforward once you know that. This article helps when trying to use manifests in VC++ 6.0 for Vista compatibilility and/or XP/Vista Themes. The author has a sample manifest but you'll probably want to dig the security section out of the doc in the previous post or search for one here.
Help with manifests[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
