|
I'm just wondering if you're using a DLL that needs .NET 2.0 with an app that's using 1.1.
Did everything work fine before .NET 2.0 was installed?
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
It is an option. Maybe one of the DLL needs 2.0 and it was using 1.1.
I have to go step by step - I guess.
The application was runnig at 1.1 but I am not sure all of the DLLs where OK.
I think that maybe using VS2005 will solve it.
|
|
|
|
|
Tal S. wrote: think that maybe using VS2005 will solve it.
At least all the code would for sure be using the same libraries 
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Sometimes I'm wondering some people says that their program run good on the debug but not on release or like Tal S. problem but I dont know why I didnt get like these errors never!? 
Did you have these problems?
|
|
|
|
|
Nope thank goodness
I've never once mixed C# in my C++ code - actually I've never used C#!
The code is being run in debug mode the OP stated...
It's really hard to debug by proxy!
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Sometime answer to questions like this question is difficult because you must use of your experience because infotmations are limited.
-----------------------
For C# I worked with C# but I think usualy I said where's my header or resource files but I think generaly C# is easier than C++ but for example see this code
[DllImport("user32.dll")]
public static extern bool SendMessage(
IntPtr hWnd,
Int32 msg,
Int32 wParam,
ref LV_ITEM lParam);
m_List.SendMessage(listView1.Handle,
m_List.LVM_SETITEM, 0, ref lvi);
|
|
|
|
|
Do you think the problem can be: #using <mscorlib.dll>?
|
|
|
|
|
I dont think problem is of using.
|
|
|
|
|
The code is written by one person...who know what is wrong...?
|
|
|
|
|
It is NOT written by one person..
|
|
|
|
|
Dear all,
I have to build a project for X64 platform. for my project i need Msi.lib to build successfully. so i included Msi.lib
After including iam getting the following error
"fatal error LNK1112, module machine type 'IA64' conflicts with target machine type 'x64' "
Any suggestion/solution is very Helpful...
Manjunath S
GESL
Bangalore
|
|
|
|
|
Sounds like you included the x64 msi.lib instead of the IA64 msi.lib. They are not the same. Check what directory you're getting the .lib file from and make sure you're using the IA64. I don't have IA64 installed on my system so I can't check what it is myself.
Judy
|
|
|
|
|
How can I know when a button has the focus?
|
|
|
|
|
ArielR wrote: How can I know when a button has the focus?
WM_SETFOCUS -- Is sent when a window has gained focus.
Override afxvoid CWnd::OnSetFocus( CWnd* ).
Insert a message map entry likewise...
ON_WM_SETFOCUS().
|
|
|
|
|
Ok, I discovered CButton::GetState(). If return 0x0008 is on Focus. Thanks
|
|
|
|
|
Actually if return & 0x0008 is non-zero then it has the focus.
It's slightly different...
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.
|
|
|
|
|
Hi,
I've encountered a problem where windows preempts for 16ms on a very simple code i'm running.
In order to check it out I've written a simple code :
while (1)
{
int t = timeGetTime();
Sleep(1);
printf ("%d,",timeGetTime()-t);
}
the result i got where interesting - on some machines i got 1-2ms and on others 16ms.
all machines run XP with no processes running in the background.
I've tried running the same process in real-time and in normal mode - the results where the same.
|
|
|
|
|
Read this[^] and this[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks,
I know that windows is not a real-time OS.
I would expect the behavior to be inconsistent, depending on many variables.
but in this case on the behavior is consistent on some machines 1-2ms and on the others 16ms.
|
|
|
|
|
Nir sheffi wrote: but in this case on the behavior is consistent on some machines 1-2ms and on the others 16ms
hence it is inconsistent.
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.
|
|
|
|
|
yes,
but consistent on the same machines
|
|
|
|
|
Nir sheffi wrote: I would expect the behavior to be inconsistent.......but in this case on the behavior is consistent on some machines 1-2ms and on the others 16ms.
Ok, so what is your question? 
The articles I linked to in my previous post gives you multiple reasons to why you won't get the control back within 1 ms if you call ::Sleep( 1 ). If you want to pinpoint exactly the reason why this is happening on the machines you've tested, I cannot help you with that for two reasons:
1. It would be a tedious job to track the reason down and it would presumably require investigation of the machines and how they are set up.
2. When the reason is found we cannot do anything about it. There's no way to change the behaviour since this is how the system works. It would simply be a waste of time.
My approach is more pragmatic...
It doesn't matter what the exact reason is in this case. On another machine it would be another reason. The fact is that ::Sleep() gives unpredictable results and if time is of the essence you should find an alternative solution, such as multimedia timers which would give the best resolution on a windows OS.
Don't spend time tracking the exact reason down because you cannot use that information for anything. It can be interesting from a technical point of view, but then you're on your own. 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Nir sheffi wrote: Hi,
I've encountered a problem where windows preempts for 16ms on a very simple code i'm running.
Hi there, you may be able to improve your timer performance by doing the following:
<br />
void SetResolution(UINT milliseconds)<br />
{<br />
TIMECAPS tc;<br />
if (TIMERR_NOERROR == timeGetDevCaps(&tc, sizeof(tc)))<br />
{<br />
static UINT wTimerRes = min(max(tc.wPeriodMin, milliseconds), tc.wPeriodMax);<br />
timeBeginPeriod(wTimerRes);<br />
m_resolution = wTimerRes;<br />
}<br />
}<br />
In addition you will get better accuracy by utilizing multi-media timers.
UINT m_timerID = timeSetEvent(m_eventDelay, m_resolution, OnTimer, (DWORD_PTR)this, TIME_PERIODIC);<br />
|
|
|
|
|
For clarity reasons:
The timeXXXX functions all apply to the multimedia timers.
Calling ::timeBeginPeriod() will not change how ::Sleep() works.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi Roger,
According to the MSDN the timeBeginPeriod API call affects the Sleep() quantum and all timers associated with the application.
http://msdn2.microsoft.com/en-us/library/ms686298.aspx[^]
However, in my experience timeBeginPeriod with standard Sleep() did not have as much of an effect!
The author of the question will certainly get best performance by utilizing multi-media timers.
Best Regards,
David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
