|
i believe they are application scope. otherwise, your app would be receiving timer messages from every other app out running on your system - this would be a tremendous waste of CPU cycles, IMO.
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
Not global. IDs must be unique per HWND.
"If the hWnd parameter is not NULL and the window specified by hWnd already has a timer with the value nIDEvent, then the existing timer is replaced by the new timer. When SetTimer replaces a timer, the timer is reset. Therefore, a message will be sent after the current time-out value elapses, but the previously set time-out value is ignored." (from MSDN docs on SetTimer).
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Wow! That was quick.  Thanks, Guys.
|
|
|
|
|
Working with VC++ 6.0 I have a problem. The CRecordView class has no DoModal() function.So I don't know how to call a dialog based on CRecordView from another dialog (based on CView for example).
E.g I tried to call a dialog with class name CRecView (based on CRecordView):
void CTestDlg::OnButton1()
{
CRecView m_Dlg1;
m_Dlg1.DoModal();
}
but without the DoModal function I can't do it.
|
|
|
|
|
|
Working with VC++ 6.0 I have a problem. The CRecordView class has no DoModal() function.So I don't know how to call a dialog based on CRecordView from another dialog (based on CView for example).
E.g I tried to call a dialog with class name CRecView (based on CRecordView):
void CTestDlg::OnButton1()
{
CRecView m_Dlg1;
m_Dlg1.DoModal();
}
but without the DoModal function I can't do it.
|
|
|
|
|
I will be packaging my MFC app with Wise.Theres a third party control that requires that olepro32 and oleaut32 be registered and installed on the users machine. I guess my question is, that if I ship the version they suggest, they are older than whats already on my win2k. If the user has newer dlls too, then these older ones I distribute wont overwrite them right? (In which case, the app should still work, I hope.).
If my shipped dlls are newer than the users dlls, then it wont mess up their machine to install mine - is that right?
Thanks,
ns
|
|
|
|
|
ns wrote:
If the user has newer dlls too, then these older ones I distribute wont overwrite them right?
Well, it depends on the installer. I don't know Wise, but I'm pretty sure you can control the way files are copied - there should be an option 'leave existing file if its version is more recent'. At least there's something like this in InstallShield.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
<old installshield="">
It is true you have the overwrite-only-if-newer flag in old InstallShield.
If you put these DLLs in your app directory, then you don't even need to worry this.
InstallShield is legacy.
You must use Merge modules (.msm) files, fill a .msi database and use the Windows Installer SDK.
System merge modules such like the ones you mention are provided by MS. VS.Net provides a lot of them in the cd.
Packages are represented by GUIDs and that's by design the installer now knows if a subpackage is already installed, needs upgrade, or has been uninstalled.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
If you put these DLLs in your app directory, then you don't even need to worry this
I highly doubt if you can put olepro32 and oleaut32 in app directory - these are core OLE libraries.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Agreed, but usually DLLs loaded automatically follow the documented scheme :
- either in current path
- or in PATH environment variable
- or system dir
So I guess this works. Requires a try though...
And I swallow a small raisin.
|
|
|
|
|
Yeah, and when you mix 'system '.dlls from app directory with real system .dlls then you'll get mysterious problems. 
Not worth the effort, IMHO.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
I don't like very much the idea of the so-called "mysterious problems". Every developer should be able to know exactly what DLLs are loaded, when, and why. If they don't, how can they debug ?
Along with static DLL dependancy walker tool, I highly recommend developers to read Matt Pietrek's articles on the net, and also download tools that for instance dynamically show loaded DLLs (introductory article here).
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
Along with static DLL dependancy walker tool,
Unfortunately, this doesn't solve all problems. Your app will load .dll from app directory, however, other parts of the system located in system32 will load *their* version. If there's some data exchange going on, and it uses internal structures which evolved in time, you're in trouble.
I remember that old issue of WDJ had very nice article on that, don't have a copy at hand however.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
you need to add the case where the DLL is an ActiveX server and needs to be registered. if you add and register a new version, everything that uses that component will be using your version.
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
To obscure even more, add Independant version ProgIds...
And I swallow a small raisin.
|
|
|
|
|
Tomasz Sowinski wrote:
I don't know Wise, but I'm pretty sure you can control the way files are copied - there should be an option 'leave existing file if its version is more recent'.
There is something like this on Wise also. Anyway the best and only thing to do is to test it :
- install a new W2000 on a test machine
- note the version of your system DLLs
- install your product & reboot
- look if they have changed
|
|
|
|
|
Disagreed. What about MS Windows MUI (Multilingual user inteface) available with W2K and XP ? (::LoadLibrary hooked by the OS).
And I swallow a small raisin.
|
|
|
|
|
I want to make some plugin for Ms Office,Excel. This plugin will be used to sign document, but I don't have any idea how to start (I'm not sure if it's possible to make it in c++, maybe I have to use Visual Basic). Does anyone have some idea? I will appreciate any help.
|
|
|
|
|
|
Is there any direct and efficient way to convert a number into std::string. Infact in order to convert a number to char * we can use sprintf or itoa etc. But i want to convert a number to std::string directly. If there any such way exists then please tell me.
|
|
|
|
|
You can use strstream.
Sonork 100.15206;PavelK
|
|
|
|
|
Pavel Klocek wrote:
You can use strstream.
... but you shouldn't, because it's deprecated.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
You can always use std::ostringstream:
using namespace std;
ostringstream os;
int x = 2002;
os << x;
string s;
s = os.str();
But I think for single int you should just use local char[] array and itoa, then assign to std::string.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
I just use something like this
std::string itostring(int val)
{
char buf[32] = {0};
sprintf(buf, "%d", val);
return buf;
}
int x = 4;
itostring(x).c_str();
Todd Smith
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
