|
You should use
SetConsoleActiveScreenBuffer(hScrBuf); to activate your source buffer for the console.
Or you should use
hSrcBuf = GetStdHandle(STD_OUTPUT_HANDLE); to get a handle to the console.
Oliver
|
|
|
|
|
Thank u verrrry much Olliver,
Actually this is the first time i using the console creation functions.
Really I appreciate it.
Thanks Once again.
|
|
|
|
|
Hi,
I'm trying to create a toolbar, that one of whose buttons opens another popup toolbar (without
the caption) if it's pressed on long enough. Anyone knows how to do this?
|
|
|
|
|
when i dragging a hyperlink from ie to my application,i can only get the url like
"http://www.microsoft.com"but how to get the corresponding title.
hello
|
|
|
|
|
Hello!!
I am trying to send and receive some data using COMM(communications ). I using C/SDK for prgramming and the OS is Win98 and Win 2000.
I have got the handle to COM port(COM port1) by the use of
lineGetID() ( using VARSTRING datastructure).
I have only modified the timeout value
(commtimeouts.ReadIntervalTimeout = 3000; and set the others to
zero)..
When I transmit the data from the client using WriteFile(), it gives error in the client
saying ERROR_ALREADY_EXISTS (0x000000b7).. When I try to open the COM
port by using CreateFile() it gives error "Access Denied".
Could you please advise what could be the problem...
Sandeep
|
|
|
|
|
My hunch is that you're not calling lineGetID() appropriately. To determine this, why not try to write to COM1 without using TAPI at all? A handle to the port can be gotten with
CreateFile("COM1",GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for your mail.. I have managed to print the device name (modem name) connected to COM1. So I think I am getting a valid handle to the COM Port. Do I have to use "Overlapped" structure at the sending end as well as the receiving end.. i.e. for WriteFile() as well as ReadFile()..
and would there be a problem if the code with the use of "OverLapped" stucture give any problem if the code is run on WIn 98 or WinNT.. I want to make the code OS independent it should run on atleast WIn 98.Win NT,Win ME,Win 2000 and Win XP.
Please help
|
|
|
|
|
Well this little piece of code shows how to use lineGetID(). Assume you've got a HCALL handle obtained with lineMakeCall in passthrough mode:
LONG res;
LPVARSTRING p_varString=NULL;
size_t size=sizeof(VARSTRING)+1024;
HANDLE hCOM;
for( ; ; ){
if((p_varString=(LPVARSTRING)malloc(size))==NULL)return FALSE;
p_varString->dwTotalSize=size;
if(lineGetID(0,0,hCall,LINECALLSELECT_CALL,p_varString,"comm/datamodem")!=0){
free(p_varString);
return FALSE;
}
else if(p_varString->dwNeededSize>size){
size=p_varString->dwNeededSize;
free(p_varString);
}
else break;
}
hCOM=*((LPHANDLE)((LPBYTE)p_varString+p_varString->dwStringOffset));
free(p_varString);
Try with this to see if you're any luckier.
As for overlapped mode, I'm afraid that if you're obtaining you're COM handle via lineGetID() instead that with CreateFile() then you must assume that the port may be in overlapped mode. This mode is supported on all Windows OSs starting from Win95. The Microsoft sample TAPICOMM shows how to deal with WriteFile() and ReadFile() handling both modes (overlapped and nonoverlapped) in a unified way.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hello!!
Thank you very much for your help , but the problem persists.. I have double checked and the error I am getting is because of the WriteFile() iteself.. I cannot open the COM port by CreatFile() because the connection is established and hence if tried to open the COM port it gives error "Access denied"....
Please help..
|
|
|
|
|
Well it's hard to think of what more to do... I suggest you try the following suit of tests:- check
WriteFile works with a handle obtained with CreateFile --just get the handle without establishing any connection before.
- Make sure the modem is behaving properly --by using some TAPI program like HyperTerminal.
- Try to determine if the handle is valid by calling other functions different from WriteFile() and checking the result (with
GetFileType, for instance).
- Make sure the modem port settings are compatible with the requirements of the modem (port speed, parity, stop bits, control flow).
- See what happens with different modems/drivers.
- See what happens with different OSs/machines.
If nothing of this sheds any light, you could try to write a little self contained program reproducing the error that we can grasp and play with.
Do not abandone all hope (yet) 
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for your reply....
I tried opening the COM port by CreateFile() and validated it by using GetFileType(). It was successfull and it seems that the handle we are getting is valid one.
Following is the code we tried with setting COMM properties but WriteFile() gives an error.
hHandleForWaitEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
overlapped.Offset = 0;
overlapped.OffsetHigh = 0;
overlapped.hEvent = hHandleForWaitEvent;
hHandleForCOMPort = CreateFile("COM2",
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
//CREATE_ALWAYS,
//NULL,
FILE_FLAG_OVERLAPPED,
NULL);
if(GetFileType(hHandleForCOMPort) != FILE_TYPE_CHAR)
{
MessageBox(NULL, "INVALID_HANDLE", NULL, 0);
}
sprintf(str1, "HANDLE of com port = %d", hHandleForCOMPort);
MessageBox(NULL, str1, NULL, 0);
//Get comm properties
GetCommState(hHandleForCOMPort, &SerialDCB);
GetCommProperties(hHandleForCOMPort, &commprop);
GetCommMask(hHandleForCOMPort, &fdwEvtMask);
GetCommTimeouts(hHandleForCOMPort, &commtimeouts);
//Set COM TimeOuts
commtimeouts.ReadIntervalTimeout = 3000;
commtimeouts.ReadTotalTimeoutMultiplier = 0;
commtimeouts.ReadTotalTimeoutConstant = 0;
commtimeouts.WriteTotalTimeoutMultiplier = 0;
commtimeouts.WriteTotalTimeoutConstant = 0;
SetCommTimeouts(hHandleForCOMPort, &commtimeouts);
//fAbortOnError is the only DCB dependancy in TapiComm.
//Can't guarentee that the SP will set this to what we expect.
SerialDCB.fAbortOnError = FALSE;
//SerialDCB.BaudRate = 115200;
//SerialDCB.ByteSize = 8;
SetCommState(hHandleForCOMPort, &SerialDCB);
strcpy(str1, "");
//write it to COM port
bResult = WriteFile(hHandleForCOMPort,
'A',
1,
&dwBytesWritten,
&overlapped);
if(bResult == 0)
{
MessageBox(NULL, "WriteFile() failed", NULL, 0);
//dwLastError = GetLastError();
sprintf(str1, "Return value of GetLastError() = %d", GetLastError());
MessageBox(NULL, str1, NULL, 0);
if(dwLastError != ERROR_IO_PENDING)
MessageBox(NULL, "dwLastError != ERROR_IO_PENDING", NULL, 0);
else
MessageBox(NULL, "dwLastError == ERROR_IO_PENDING", NULL, 0);
}
MessageBox(NULL, "SUCCESS", "SUCCESS", 0);
/*************************************************************/
|
|
|
|
|
Well, I'm running out of ideas but two things in your code caught my eye. Not that I think these will account for the problem, but it may be worth checking:- You've opened the port with
FILE_SHARE_READ|FILE_SHARE_WRITE: Microsoft docs say dwShareMode must be zero for communications resources.
- The piece of code
if(bResult == 0)
{
MessageBox(NULL, "WriteFile() failed", NULL, 0);
sprintf(str1, "Return value of GetLastError() = %d", GetLastError());
...should be written
if(bResult == 0)
{
DWORD dwLastError = GetLastError();
MessageBox(NULL, "WriteFile() failed", NULL, 0);
sprintf(str1, "Return value of GetLastError() = %d", (int)GetLastError());
...to avoid the possibility of MessageBox altering the error code.
Tell us what this leads to...
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I have two ComboBoxes on a dialog, the contents of Combo2 is dependant on the selection made in Combo1. When I make a selection from Combo1 using the mouse I jump to the function handling the CBN_SELENDOK message where I fill Combo2 with the relevant data.
If instead of using the mouse I use the keyboard and tab into Combo1 and then out of it I do not trigger the CBN_SELENDOK message. Nor do I trigger CBN_SELCHANGE, these seem to be the correct messages according to my understanding of the MSDN articles.
I am using Chris Maunder's Autocomplete ComboBox which fills the EditBox with the result as you type in characters. This could be masking the correct message but I doubt it and my understanding of and ability to use Spy++ sucks big time. I tried seeing the messages used in the ComboBox with Spy++ but there were no CBN_* messages available.
What message should I be reacting too from the ComboBox when I tab out of it after making a selection?
Is there a decent tutorial somewhere on using Spy++ as I seem to have no idea on using it effectively?
Michael Martin
Pegasystems Pty Ltd
Australia
martm@pegasystems.com
+61 413-004-018
|
|
|
|
|
I am only guessing so you might want to look it up in the MSDN! (I don't have the trusty msdn library with me at the moment).
Going from memory:
I think the behaviour you are experiencing is by design. If you tab to a combo box and then leave it using tab the selection has not changed, therefore the CBN_SELCHANGE and CBN_SELENDOK messages are not fired.
Can I suggest trapping the lose focus event on the window (WM_KILLFOCUS I think)
hope this helps
Matt
------
Accept that some days you are the pigeon and some days the statue.
|
|
|
|
|
Matt
thanks for the response I will look into it, though I think I haven't explained the situation correctly.
I tab to Combo1, make a selection using the arrows or by typing some letters then the autocompletion makes the selection for me. Then I tab out to Combo2, I think this should have kicked off some message from Combo1.
Does anyone know what message it would be.
Michael Martin
Pegasystems Pty Ltd
Australia
martm@pegasystems.com
+61 413-004-018
|
|
|
|
|
For VB Programmers, to display recordsets is so ease.
but, not for a vc++ programmer i think.
A VB programmer can use dbgrid control bound to recordsets to display .
Grid controls i've used do not provide a way to connect to a database recordset.
anybody knows ? :rose
XiaoPeng
|
|
|
|
|
Has anyone got CSystemTray to work in an MDI app?
I have heard that a WM_SHOWWINDOW message is caused by a call to
SetWindowPlacement. However a grep "SetWindowPlacement" *.{cpp,h} of the
MFC VC++ 6.0 sources reveals just two occurences in wincore.cpp. I was expecting to
some more occurences in winmdi.cpp.
I tried integrating CSystemTray into a fresh MDI app but still could not get it to work.
I just want the app to react to the main window being maximised and minimised without the
need for a button which explicitly instructs the app to dive into the system tray
as is the case for the demo app and John Xavier's 'Address' program.
Thanks,
-jdt
|
|
|
|
|
In __stdcall calling convention, the callee cleans the stack, so it can not be a vararg function.
In __cdecl calling convention, the calling function cleans the stack, so it can be a vararg function.
I do not understand "the calling function cleans the stack, so it can be a vararg function" and "the callee cleans the stack, so it can not be a vararg function".
Can you explain the mechanism of stack cleaning and vararg function?
Thanks.
Maer
|
|
|
|
|
The parameters to a function are passed on the stack. When the function returns, those parameters are removed from the stack. One difference in the calling conventions is which code removes them, the function itself or the code that called the function.
"vararg" means variable number of arguments, like printf(). Since the C implementation of variable arguments doesn't tell the function how many parameters were passed, only the caller knows how many, so only the caller can remove them from the stack.
--Mike--
http://home.inreach.com/mdunn/
You are the weakest link, GOODBYE!
|
|
|
|
|
Thank pal.
You help a lot.
Best regards.
Maer
|
|
|
|
|
I have a CList of ptrs (ptrList) to CItems in a supporting class (CGroup) of my program, with an override of SerializeElements. This works fine until I add a second CArray or CList of the same type of ptr as a member of CMainframe. Then I get a linker error:
Group.obj : error LNK2005: "void __stdcall SerializeElements(class CArchive &,class CItem * *,int)" (?SerializeElements@@YGXAAVCArchive@@PAPAVCItem@@H@Z) already defined in MainFrm.obj
I gather that the linker is unable to deal with an alternate version of the SerializeElements function, but how do I get around this while keeping the SerializeElements override in the CGroup.cpp file?
Any help is appreciated.
Thanks
WJ
|
|
|
|
|
So you have two definitions of SerializeElements(CArchive&, CItem **, int)? Do they differ?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I have only created one definition of SerializeElements, the one in class CGroup. This was needed to serialize the items pointed to rather than the ptrs in the list. I'm guessing that the linker is somehow first linking the default version when it encounters it in CMainFrame, then is unable to resolve what it percieves as an alternate version ( which does differ in function ) in CGroup.
Actually, the SerializeElements method will never be used in the MainFrame Array, but the linker doesn't know that.
--WJ
|
|
|
|
|
You should make one or both SerializeElements static. 'Static' function is visible only within the containing .cpp or .c file.
The other solution would be putting these functions in unnamed namespace.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
How do I wait for a worker thread to finish? I am trying to use WaitForSingleObject(), waiting on the thread handle, but it does not want to wait for the thread to finish. What else can I use? Or am I approaching this all wrong?
In my dialog based app's InitInstance() function I have this code
...
dlg.DoModal();
CWinThread *pThread = WriteLog (_T("GetSamples : Done"));
TRACE ("Wait for thread at 0x%08X\n", pThread);
WaitForSingleObject(pThread->m_hThread, WAIT_OBJECT_0);
TRACE ("Exiting\n");
return FALSE;
}
Here is my WriteLog() function
UINT WriteLogThreadFunction(LPVOID lp)
{
TRACE ("WriteLogThreadFunc() Start\n");
LPTSTR LogEntry = (LPTSTR)lp;
CMutex mutex(FALSE, _T("WriteLog - {AE4E28C0-84E6-11d5-B625-F80C283F7922}"));
CSingleLock lock(&mutex, FALSE);
lock.Lock();
CRotatingLog rl(_T("C:\\Bird_Log.txt"), 500, 100);
rl.AddLine(LogEntry);
delete[] LogEntry;
TRACE ("WriteLogThreadFunc() End\n");
return 0;
}
CWinThread* WriteLog (LPCTSTR EntryString)
{
COleDateTime dt = COleDateTime::GetCurrentTime();
CString LogEntry = dt.Format("%d/%m/%y %H:%M:%S - ");
#ifdef _DEBUG
LogEntry += _T("DEBUG - ");
#endif
LogEntry += EntryString;
LPTSTR String = new TCHAR[LogEntry.GetLength() + 1];
_tcscpy(String, LogEntry);
TRACE ("Starting WriteLogThreadFunc()\n");
return AfxBeginThread(WriteLogThreadFunction, (LPVOID)String);
}
And here is the debug output
Starting WriteLogThreadFunc()
Wait for thread at 0x00771CC0
Exiting
The thread 0xFFF552F3 has exited with code -1 (0xFFFFFFFF).
Detected memory leaks!
Dumping objects ->
thrdcore.cpp(166) : {4004} client block at 0x00771CC0, subtype 0, 112 bytes long.
a CWinThread object at $00771CC0, 112 bytes long
{4003} normal block at 0x00771820, 46 bytes long.
Data: <29/08/01 17:12:3> 32 39 2F 30 38 2F 30 31 20 31 37 3A 31 32 3A 33
Object dump complete.
The thread 0xFFF5443B has exited with code 2 (0x2).
TIA
Pete
---
Multitasking: Screwing up several things at once.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
