|
Dear all
i just created a simple project using vc++ 2005 express edition, but after i built this project, one issue occurred. output showed :"cl : Command line error D8016 : '/MT' and '/clr' command-line options are incompatible". so what happened?
second issue: when i add one item: windows form. pc showed me:you are adding a CLR component to a native project.your project will be converted to have common project language runtime support. so what happened? thanks a lot.
i am looking forward to your news.
Li Zhiyuan
5/10/2006
|
|
|
|
|
If you want to use the .NET framework in your C++ app then you'll need to create a managed
assembly.
If you want a native Win32 application then you won't be able to use any CLR/.NET/managed code.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Dear all
i just created a simple project using vc++ 2005 express edition, but after i built this project, one issue occurred. output showed :"cl : Command line error D8016 : '/MT' and '/clr' command-line options are incompatible". so what happened?
second issue: when i add one item: windows form. pc showed me:you are adding a CLR component to a native project.your project will be converted to have common project language runtime support. so what happened? thanks a lot.
i am looking forward to your news.
Li Zhiyuan
5/10/2006
|
|
|
|
|
I have a DATE type variable and i am trying to display the date and time stored in it but i am not able to succeed. can anyone give me any suggestions? The date I am trying to display is in the form of FILETIME. Thanks in advance.
Regards,
Vijay.
God may not give us what we 'want', but he surely gives us what we 'need'.
|
|
|
|
|
Try FileTimeToSystemTime function.
|
|
|
|
|
Thanks. i had the problem solved immediately after i posted the question here. 
fd0129002 wrote: Try FileTimeToSystemTime function.
yes, I used the same function. Thanks anyways.
Regards,
Vijay.
God may not give us what we 'want', but he surely gives us what we 'need'.
|
|
|
|
|
hi,
You can also use (in VC++, at least):
CTime time = CTime::GetCurrentTime ();
CString szEditTime = time.Format ( "%A, %d.%B.%Y, %H:%M:%S" );
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
hi i have to get the user login path ie c:\documents and settings\allusers in a system. how to do this
Arise Awake Stop Not Till ur Goal is Reached.
|
|
|
|
|
Try SHGetSpecialFolderPath function.
|
|
|
|
|
What is purpose of padding of 2-2 bytes in debug build??
What are other important differences in Release and debug builds??
Thanks & Regards,
Sandip.
|
|
|
|
|
SandipG wrote: What is purpose of padding of 2-2 bytes in debug build??
????
Steve
|
|
|
|
|
I am not sure what you mean. Usually the only reason for padding in debug is so that an overrun can be detected. I have seen that in the VC 1.52 and below compilers, but since VC6 and above have come out – I have not looked.
You will need to be more specific.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
There is padding of 2 bytes before and later after each variable in debug build.
What is this paddign for??
|
|
|
|
|
I would assume that they are used for detecting over-runs and under-runs by the debugger, so that a crash does not occur during debugging. Of course I do not know this for a fact and may be some else does. All I do know is one of my environments padded arrays in debug mode and it caught me off guard when runtime analyses showed I was short one byte, because the runtime was not padded. That, of course, was my fault, but the fault was hidden in debug mode.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
how to control parallel datapins to implement a circuit with led using window xp visual C++ ?? HELP PLZZ
any useful source code or website ??
|
|
|
|
|
Someone said that PostQuitMessage function does not really send a WM_QUIT message to the message queue of the calling thread. I wonder what does this function exactly do.
//Here is a simple test code
/*If PostQuitMessage function sends a WM_QUIT message to the message queue of the calling thread, GetMessage(..., hwnd, ..., ...) can't get the WM_QUIT message, the application won't leave the message loop.
But in this example:
1.compile the source ;
2.Ctrl+F5 to run it;
3.D&D to move the window;
4.press the corss to close window;
5.found that the application process disappear from the "task manager "
It seems that GetMessage(..., hwnd, ..., ...) got the WM_QUIT message.
Someone said it's because of that PostQuitMessage is called before DestroyWindow.
But I can't get the same result when debugging by F5.
Sorry for my poor English......thanks for your attention.
*/
#include <windows.h>
#include <stdio.h>
LRESULT CALLBACK WinSunProc(
HWND hwnd, // handle to window
UINT uMsg, // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
);
int WINAPI WinMain(
HINSTANCE hInstance, // handle to current instance
HINSTANCE hPrevInstance, // handle to previous instance
LPSTR lpCmdLine, // command line
int nCmdShow // show state
)
{
BOOL bRet = FALSE;
WNDCLASS wndcls;
wndcls.cbClsExtra=0;
wndcls.cbWndExtra=0;
wndcls.hbrBackground=(HBRUSH)GetStockObject(WHITE_BRUSH);
wndcls.hCursor=LoadCursor(NULL,IDC_CROSS);
wndcls.hIcon=LoadIcon(NULL,IDI_APPLICATION);
wndcls.hInstance=hInstance;
wndcls.lpfnWndProc=WinSunProc;
wndcls.lpszClassName="Weixin2003";
wndcls.lpszMenuName=NULL;
wndcls.style=CS_HREDRAW | CS_VREDRAW;
RegisterClass(&wndcls);
HWND hwnd;
hwnd=CreateWindow("Weixin2003","CreateWindow",WS_OVERLAPPEDWINDOW,
0,0,600,400,NULL,NULL,hInstance,NULL);
ShowWindow(hwnd,SW_SHOWNORMAL);
UpdateWindow(hwnd);
MSG msg;
while((bRet = GetMessage(&msg,hwnd,0,0)) != FALSE)
{
/*if(bRet == -1)
{
break;
}*/
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return 0;
}
LRESULT CALLBACK WinSunProc(
HWND hwnd, // handle to window
UINT uMsg, // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
)
{
DWORD dwCurThreadID = GetCurrentThreadId();
switch(uMsg)
{
case WM_CHAR:
break;
case WM_LBUTTONDOWN:
break;
case WM_PAINT:
HDC hDC;
PAINTSTRUCT ps;
hDC=BeginPaint(hwnd,&ps);
TextOut(hDC,0,0,"WM_PAINT",strlen("WM_PAINT"));
EndPaint(hwnd,&ps);
break;
case WM_CLOSE:
PostQuitMessage(0);
//DestroyWindow(hwnd);
break;
case WM_DESTROY:
//PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd,uMsg,wParam,lParam);
}
return 0;
}
|
|
|
|
|
|
Steve, thanks a lot for your answer.
More questions:
1.Where can I get more information about how the PostQuitMessage virtually sends a message?
2.Why Microsoft made such a difference between PostQuitMessage and PostThreadMessage(..., WM_QUIT, ..., ...)? How can we take advantage of this difference?
|
|
|
|
|
There is a queue status flag assigned per queue. When the thread is running it can request (GetQueueStatus) the status of its queue and observe its value (QS_PAINT, QS_QUIT, ...). This request happens when the thread calls GetMessage or PeekMessage APIs. Based in the status returned, this APIs process the appropriete message from the queue and return the control.
Now PostQuitMessage doesn't post a WM_QUIT message into the queue but only set QS_QUIT flag on queue status. Then if GetMessage [or PeekMessage] meet QS_QUIT flag, they return WM_QUIT message as if it were in the queue itself.
In contrast, PostThreadMessage posts the WM_QUIT message into the queue without settiong the QS_QUIT flag. So the GetMessage [or PeekMessage] gets the WM_QUIT message from the queue really.
Why so? Actually there are two reasons.
*) Security. It might be possible that the system will fail to reserve memory for another queue entry and thus the WM_QUIT message will not enter the queue. The point is that if the app wants to quit, it should quit surely.
*) Low level priority. WM_QUIT should be processed after all the messages from the queue are processed. This is important because it will allow the application finish its job and then [when no posted messages waiting] to exit. The idea is that when GetMessage detects QS_QUIT flag, it returns WM_QUIT [this is virtual message] only when the queue becomes empty and thus ensuring that the WM_QUIT is processed the last.
--
=====
Arman
|
|
|
|
|
Arman Z. Sahakyan wrote: Low level priority. WM_QUIT should be processed after all the messages from the queue are processed. This is important because it will allow the application finish its job and then [when no posted messages waiting] to exit. The idea is that when GetMessage detects QS_QUIT flag, it returns WM_QUIT [this is virtual message] only when the queue becomes empty and thus ensuring that the WM_QUIT is processed the last.
I have a question to that, this means that you violate event order? When someone posts a quit message, why would you want to move up later messages (in the queue) and process them before the WM_QUIT?
|
|
|
|
|
... this means that you violate event order?
Actually not me. 
Ok, the rule violates, though partially. From the following code, it is guarranted that the application will exit after it's been processed the user defined message [generally, any posted [not sent] messages].
PostQuitMessage(0);
PostMessage(hwnd, WM_SOME_USER_DEFINED, 0, 0);
It is partial violation because the queue, as it is, bares no vialoation. Why? Simply because the WM_QUIT has not been there.
When someone posts a quit message, why would you want to move up later messages (in the queue) and process them before the WM_QUIT?
To keep the integrity of the messages posted. It is possible that the application may be in a job whose integrity is defined by multiple posted messages [IOW a group of messages may be doing a single job]. Rephrased, This is a guard against possible harm inside the application logic.
--
=====
Arman
|
|
|
|
|
Thanks all.
I think I have to learn something about Windows Message from the most basic level...
|
|
|
|
|
Thanks for the feedback. Good to learn something new about Window's event handling!
I can understand that paint and mouse messages have a special handling (low priority generation) as MS has a GUI centric design... however I am surprised that MS hasn't stopped the special cases here. For example asynchronous network events (FD_ACCEPT, FD_READ) are posted to the queue and recurring is enabled by calling the matching network function, but on the other hand recurring timer events have again a special handling... kinda inconsistent. WM_QUIT came really as a surprise for me, I see your point, just not sure if it really is necessary to guard application logic at this late shut-down stage.
/Moak (Event violator le Grande)
|
|
|
|
|
background: I have an application that will call functions in a Win32 DLL, I wish to have a single function in the DLL that accepts two strings(webservice name, text to be passed to the webservice) and then calls the webservice passed in passing it the text.
This is to allow for the addition of new web services without the need to recompile the DLL, just to add a config to the calling app with the name of the new web service and the text to be passed in. The Dll only needs to pass back a success or fail to the calling app. can some help with how Can someone give me some guidance on this. I am not very strong with C++ so your patiance is much appriciated.
|
|
|
|
|
rluckwell wrote: This is to allow for the addition of new web services without the need to recompile the DLL, just to add a config to the calling app with the name of the new web service and the text to be passed in.
You need more that a "name" to use a web service. 
led mike
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
