|
tuxyboy wrote: Is there a way to test if a dll which needs to be registered (either way) is registered correctly on that particular PC?
One would like to think that the DLL's DllRegisterServer() function would return an error code if that happened.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
The case is as follows.
The dll's are installed and registered during the app's first install or when a new version is available. BUT when it's not I don't want to call registerserver. I don't know how but it happens sometimes that the already installed files (registered dll's) became unregistered somehow and stop working even if the updater app doesn't touch them, cause there is no new version available. The files are there but unregistered. So I want a method that every time the updatecheck runs it tests all the dll's needed to be registered even if it's not an updatable file, just to be on the safe side.
|
|
|
|
|
there is no harm to register a dll multiple times, no reference count is kept, so this would simplify what you're trying to do with your installer.
simply register the dll after it gets installed!
Yours Truly, The One and Only!
|
|
|
|
|
I am using NTGraph3D for obtaining 3Dplots.
I would like to know how to print the 3D-Plots obtained.
Thanks in advance for the reply.
|
|
|
|
|
Hi all,
I wonder if this doable. I have 2 CButton-derived classes (I don't have the source code for any of them): CButton1 and CButton2. Now I want to use CButton1 for XP or later, and use CButton2 for Win2k or older.
Since controls are declared in the .h file, how do we differentiate the OS version (if feasible). I want to achieve the following (pseudo-code):
class CMyDlg : public CDialog
{
...
enum { IDD = IDD_MYDLG };
if(RunningWindowsVersion>=XP)
CButton1 m_btn1;
else
CButton2 m_btn1;
...
...
}
If I can do this, I don't have to compile 2 versions of my program. I would appreciate it if anyone has any pointer on this matter. Thanks.
|
|
|
|
|
not like this... but you can use polymorphism. say, in your header file, you use a CButton*, and in the constructor, you detect the os, and allocate the whether a CButton1* or a CButton2* as you like. the only condition for this to work is that CButton1 and CButton2 classes must inherit from CButton base class
|
|
|
|
|
Does this mean I have create the button dynamically during run time, not thru ClassWizard?
Do you have any sample code or snippet on how exactly to use your approach?
Thanks.
|
|
|
|
|
in the .h :
class CWatever {
CButton* m_button;
public:
CWatever();
~CWatever();
};
in the .cpp :
CWatever::CWatever() {
if (OSType() == "XP") {
m_button = new CButton1();
}
else {
m_button = new CButton2();
}
}
~CWatever::CWatever() {
delete m_button;
m_button = NULL;
}
then you use the m_button as if it was a simple button pointer...
m_button->SetWindowText(_T("Push Me !"));
|
|
|
|
|
Determining the OS is not so hard. Take a look at the article "XWinVer - Simple class to get windows OS version" by Hans Dietrich.
Regards,
Marcus.
|
|
|
|
|
I think you missed my point. My problem is not in determining the OS version, i know it's pretty easy. What I need to know is how to declare a control differently based on the os version.
|
|
|
|
|
I'm sorry, I got your sentence "how do we differentiate the OS version (if feasible)" wrong 
Regards
Marcus
|
|
|
|
|
|
For a compile-time version, how about something like:
#if _WIN32_WINNT >= 0x0501
CButton1 m_btn1;
#else
CButton2 m_btn1;
#endif
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
i thought of this, but the OP seems to want to determine the OS at runtime...
|
|
|
|
|
Which is why I specifically stated "compile-time version." 
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I guess he wants the decision about the used button class during runtime and not during compile time... 
cheers,
mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy."
|
|
|
|
|
See here.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
i want to diaplay a modeless listbox on button click.i m gvng my listbox which in one class from some other class. i hav made a new class in which i have made my own addstring function which is like this:
int CMyList::Addition(LPCTSTR lpszItem)
{
return CListBox::AddString(lpszItem);
}
i have declared an object of CMyList as:
CMyList myobj;
obj.Addition("hye");
but i m getting exception error.
can anyone tell me how to rectify this exception.
is there any other method to do so??
NT
|
|
|
|
|
I guess you have to call the CListBox member function Create(...) before adding items to the list.
Regards
Marcus
|
|
|
|
|
why and how???????????????
NT
|
|
|
|
|
Before calling Create(...) no window exists for the list box. And you can't add items to the list before creating a corresponding window. See MSDN for how to use the function.
Regards,
Marcus.
|
|
|
|
|
Did your MyListBox class derive from CListBox?
Then the Create()-code should already be there and be used.
But then you could simply write AddString() in you class function, as "public derivation" means the derived class *IS A* base class in every respect.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
yes i have derived my new class from CListBox
nw do i hav to use create() function????????
NT
|
|
|
|
|
Yes. When you want to Create your Listbox. From your description, that would be the button-click-handler.
Remember, though, that a local MyListBox variable would be destroyed on leaving the Button-click-handler. But you wanted your ListBox modeless and staying on the screen even when your program continues.
You would possibly need to make a member variable in its parent for it.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
It depends. If in your case myobj is a member of your dialog where the list box belongs to and if myobj is associated with that list box, then no. If you created myobj in some function locally, then yes. Maybe you can have a look at the MFC Controls -> List controls section for some sample code to study.
Regards
Marcus
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
