|
Iain Clarke wrote: for (i = 0; i < 9860708750; i++)
Will this run forever (since i will always be less than 9 billion)?
"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
|
|
|
|
|
Yes! You've caught my deliberate error!
Maybe i was defined as __int128....?
The other remote possibility is I made up a number and it kinda got away from me....
Iain.
|
|
|
|
|
|
In one of table field which I kept memo type (Access),use to have data of around 280 characters long key for some Image purpose. In VB recordset connectivity works fine. But when I developed VC++ application using Recordset simple connectivity. It gives error data truncated
while opening database. I done lot of R&d and found If I make my data type as text
( I cannot store my key in text) ,Everything works fine. This is very strange problem.
I dont have now time to learn OleDB or ADO . Is there any solution to this problem.
VB does not give any problem.
|| ART OF LIVING ||
|
|
|
|
|
I'm not sure how to fix your problem with Memo,
but if you change it to OLE Object it will work.
OLE Object can store CByteArray so you can insert
any binary data, not just text.
<br />
CByteArray m_MyKey;<br />
<br />
RFX_Binary(pFX, _T("[MyKey]"), m_MyKey);
|
|
|
|
|
After Lots of ups and down I found answer by myself, nearby to your answer
// RecordSet Connectivity ODBC MFC internals, autogenerated --
void tt::DoFieldExchange(CFieldExchange* pFX)
{
//{{AFX_FIELD_MAP(tt)
pFX->SetFieldType(CFieldExchange::outputColumn);
RFX_Long(pFX, _T("[Id]"), m_Id);
RFX_Text(pFX, _T("[tt]"), m_tt); // tt is my memo in database.
//}}AFX_FIELD_MAP
}
Now for memo field which exceeds 255 limit ,we can add fourth attribute to RFX_Text
RFX_text(pFX,_T("tt"),m_tt,500); // My Limit is 500 currentely but can be large.
And Now code works very fine
|| ART OF LIVING ||
|
|
|
|
|
I am using Microsoft Visual C++ 6.0 Professional to develop a program that will output data to avionics equipment.
My question is how to run the profiler to do timing analysis on my program.
Here are some details on what I'm trying to do:
The program is dialog based. The dialogs are used to capture user input values for the data to be output.
I created a timer that looks like:
m_UpdateTimer = SetTimer (1, 1, NULL);
From what I understand, this timer should trigger every 1 ms.
I created a message map to trigger when the timer ticks:
BEGIN_MESSAGE_MAP(CbrsttDlg, CDialog)
ON_WM_TIMER()
...
END_MESSAGE_MAP()
I have a procedure which is called every time the timer triggers:
MyProg::OnTimer() { ... code .. }
My procedure does get called regularly. However I don't think it's being called every 1 ms. I want to find out how often this procedure is being called .
I know that there is a profiler that does timing analysis that comes with the Microsoft Visual Studio. I believe I have it installed.
I have set the "Enable Profiling" option on the Link tab in the Project settings.
Under the Build menu there is a Profile... option. I clicked that and chose "Function Timing". According to the MSDN library, if I want to do timing on a single procedure I need to put this in the advanced Settings: box.
MSDN says:
"Or, if you are in the development environment, you might type the following in the Advanced settings text box of the Profile dialog box,
SF ?MyFunc@@YAXPAH@@"
I looked up my function in the map file. The line in the map file says:
0001:00007980 ?OnTimer@CbrsttDlg@@IAEXI@Z 00408980 f brsttDlg.obj
So I put :
SF ?OnTimer@CbrsttDlg@@IAEXI@Z
into the Advanced settings: box.
When I click OK on the Profile box it says in the profile tab:
PREP : fatal error PRF1011: cannot open file p:\brs_taws_sw\tools\brstaw_test_tool\brstt\debug\sf.exe
Now, I'm completely lost. Why is it looking for sf.exe? 
Supposedly (according to MSDN lib), the SF is an option to the PREP tool.
I have googled looking for information on how to use the profiler but haven't come up with anything useful. Some of the info I found says to use some .ini files for PREP and a couple other things. But I don't know where these files are, how they get created, or what to put in them.
If someone can point me to a site with some useful information for a newb, it would be greatly appreciated.
Thanks in advance.
|
|
|
|
|
You are correct when you say that your proc wont be called every 1 mSec, far from it in fact. So, there are two ways of looking at this:
1) Finding out what the timing actually is. This can easily be done with the excellent CPerfTimer class by Dean Wyant dwyant@mindspring.com. I think it is available on codeproject.com.
2) Improve the timer resolution and accuracy. This can be done quite simply using multimedia timers. You should be able to get a lot better accuracy than you get with a standard windows timer but you might not get the 1mSec timing that you require. I have some info/code frags on using multimedia timers if you like.
Hope this helps.
Tony
|
|
|
|
|
Thanks for the pointer. I reimplemented the timer using a multimedia timer (using an example I found on the web). It seems vastly better than what I had before.
But...my question still remains.
Does anyone know how to use the Visual Studio Profiler?
|
|
|
|
|
wings2 wrote: From what I understand, this timer should trigger every 1 ms.
No way Windows can deliver that frequency. SetTimer works reasonably well for ranges over half a second, not milliseconds.
Anyway, if you are looking for a profiler, I suggest GlowCode[^] - has a free trial period. Not sure if it works with VC6, though.
|
|
|
|
|
wings2 wrote: I created a timer that looks like:
m_UpdateTimer = SetTimer (1, 1, NULL);
From what I understand, this timer should trigger every 1 ms.
Wishful thinking, but since Windows is not a RTOS, it's just not possible. The best you could hope for is about 15ms.
"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'll save you some trouble...
There's almost no chance whatsoever that your routing is getting reliably called every millisecond. Like WM_PAINT, WM_TIMER is only generated if the message queue is quiet.
If you just want it "as often as I can, and at most 1000 times a second", then you might be lucky.
Otherwise, you're going to have to use a separate thread, and some mechanism like waitable timers. If you are *REALLY* insistent on the interval, then windows is not going to be real time enough for deterministic real time behaviour...
Hopefully this gives you some parallel thoughts, even if it went nowhere near answering your question,
Iain.
|
|
|
|
|
Nemanja Trifunovic wrote: No way Windows can deliver that frequency. SetTimer works reasonably well for ranges over half a second, not milliseconds.
Well, not exactly.
I just tested SetTimer, and the minimum increment it works with is 1/100 of a second (not 1/1000). But with increments in multiples of 1/100 of a second it is extremely accurate. Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
An interval less than 10 milliseconds is treated as 10. An interval that is not a multiple of 10 is bumped up to the next multiple of 10.
The docs on SetTimer mention a USER_TIME_MINUMUM but #defining this to 1 didn't seem to matter. The minimum increment was still ten milliseconds. (OS - Win 2000).
|
|
|
|
|
Force Code wrote: Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
Come to think of it, being off by an average of 1/50000 of a second could be attributed to the overhead of OutputDebugString(GetCurrentTime()).
|
|
|
|
|
Force Code wrote: Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
ummm - are they using the same clock?  I think you'd need to compare the values against a
real-time clock.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Force Code wrote: Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
Mark Salsbery wrote:
ummm - are they using the same clock? I think you'd need to compare the values against a real-time clock.
I just tried it with QueryPerformanceCounter. It showed the WM_TIMER msgs were only off by an average of .0032%.
According to the SDK docs, QueryPerformanceCounter returns TRUE "if the installed hardware supports a high-resolution performance counter" (which it did in my case).
-- modified at 16:52 Tuesday 19th June, 2007
|
|
|
|
|
Well that's good news.
The most troubles I've ever had programming (and I'm still dealing with it now) is trying to
get any kind of close-to-real-time timing on a PC.
On my dual Xeon XP development machine, I get very precise timing. On another P4 Windows 2000
box I have, the timing is horrible. How much is OS, how much is hardware, I still have no idea.
I do know I have to synchronize certain timings between them (and more importantly, between
customer machines)) in real-time and it's a nightmare
Some possibly interesting articles...
Time is the Simplest thing...[^]
Precision is not the same as accuracy[^]
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark Salsbery wrote: Some possibly interesting articles...
Time is the Simplest thing...[^]
Precision is not the same as accuracy[^]
From Precision is not the same as accuracy[^]: "If you're looking for high accuracy, then you'd be better off playing around with the QueryPerformanceCounter function."
|
|
|
|
|
Right I'm dealing with varying 3rd party hardware clocks. 
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Force Code wrote: I just tried it with QueryPerformanceCounter. It showed the WM_TIMER msgs were only off by an average of .0032%.
Correction: It was actually .0032, or .32%.
|
|
|
|
|
Hi,
We have an install batch file which needs to run at administrator level on all machines on our network. Is there a way to temporarily switch to administrator level programmatically?
Cheers,
Tony
|
|
|
|
|
You want to challenge windows security !
|| ART OF LIVING ||
|
|
|
|
|
Check out LogonUser(), ImpersonateLoggedOnUser(), and CreateProcessAsUser().
"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
|
|
|
|
|
First off, I'm running Visual C++ 6.0. I've got a DLL project that runs a batch file that uses the Message Compiler to create the .rc and .h file from a .mc file, then uses the Resource Compiler to create the .res file, and finally uses the linker to create the DLL from the .res file. What I'd like to do is to get the VERSIONINFO information into the .res or .rc file so that we can see this version information in the DLL when the user right clicks on the DLL in Explorer and selects Properties. Does anyone know a way to do this?
|
|
|
|
|
I don't know of a prepackaged way, but you should do it with a bit of programming.
1/ Make a resource only dll, and create the VERSIONINFO in it the way you'd like.
2/ Make a small program to merge the version resource into the MC created one - Have a look at BeginUpdateResource, UpdateResource, EndUpdateResource for the MC one, and FindResource et al for the versioninfo one.
3/ Add the mergeres.exe program to your custom build steps.
I didn't say it would be eeeeasy....
Iain.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
