|
You can use the SRCINVERT operator of the BitBlt()[^] function.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
Hi,
I am using to named pipes to communicate between a DOS console program "the server"
and a Windows "client" program
Here is the what I have coded
DOS Server
CreateNamedPipe
CreateEvent 1) for read 2) for write (used in the overlapped structure) of the Readfile
and Writefile API
DuplicareHandle - used to copy over the file handle created by the CreateFile
in the Windows Client program
WriteFile -- with a OVERLAPPED structure having a event used by CreateEvent
Windows program
CreateFile using the same name (pipename) as the one used in CreateNamedPipe in the DOS server
Openevent used to copy events created by the CreateEvent in the DOS Server
Readfile using a OVERLAPPED structure which has the same named event used by the WriteFile
I must be missing something as I get good retuen codes but can get the data over to the Windows program
|
|
|
|
|
Please post relevant code and indicate what data is being sent and what is being received.
|
|
|
|
|
ForNow wrote: I must be missing something as I get good retuen codes but can get the data over to the Windows program
I am afraid i am not able to understand your question, what are you missing good return code or actual data transfer?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Try this: Creating Named Shared Memory.
**First Process**
The first process creates the file mapping object by calling the `CreateFileMapping` function with `INVALID_HANDLE_VALUE` and a name for the object. By using the `PAGE_READWRITE` flag, the process has read/write permission to the memory through any file views that are created.
Then the process uses the file mapping object handle that `CreateFileMapping` returns in a call to `MapViewOfFile` to create a view of the file in the process address space. The `MapViewOfFile` function returns a pointer to the file view, `pBuf`. The process then uses the CopyMemory function to write a string to the view that can be accessed by other processes.
Process 1 code:
#include <windows.h>
#include <stdio.h>
#include <conio.h>
#include <tchar.h>
#define BUF_SIZE 256
TCHAR szName[]=TEXT("Global\\MyFileMappingObject");
TCHAR szMsg[]=TEXT("Message from first process.");
int _tmain()
{
HANDLE hMapFile;
LPCTSTR pBuf;
hMapFile = CreateFileMapping(
INVALID_HANDLE_VALUE,
NULL,
PAGE_READWRITE,
0,
BUF_SIZE,
szName);
if (hMapFile == NULL)
{
_tprintf(TEXT("Could not create file mapping object (%d).\n"),
GetLastError());
return 1;
}
pBuf = (LPTSTR) MapViewOfFile(hMapFile,
FILE_MAP_ALL_ACCESS,
0,
0,
BUF_SIZE);
if (pBuf == NULL)
{
_tprintf(TEXT("Could not map view of file (%d).\n"),
GetLastError());
CloseHandle(hMapFile);
return 1;
}
CopyMemory((PVOID)pBuf, szMsg, (_tcslen(szMsg) * sizeof(TCHAR)));
_getch();
UnmapViewOfFile(pBuf);
CloseHandle(hMapFile);
return 0;
}
**Second Process**
A second process can access the string written to the shared memory by the first process by calling the `OpenFileMapping` function specifying the same name for the mapping object as the first process. Then it can use the `MapViewOfFile` function to obtain a pointer to the file view, `pBuf`. The process can display this string as it would any other string. In this example, the message box displayed contains the message "Message from first process" that was written by the first process.
Process 2 code:
#include <windows.h>
#include <stdio.h>
#include <conio.h>
#include <tchar.h>
#pragma comment(lib, "user32.lib")
#define BUF_SIZE 256
TCHAR szName[]=TEXT("Global\\MyFileMappingObject");
int _tmain()
{
HANDLE hMapFile;
LPCTSTR pBuf;
hMapFile = OpenFileMapping(
FILE_MAP_ALL_ACCESS,
FALSE,
szName);
if (hMapFile == NULL)
{
_tprintf(TEXT("Could not open file mapping object (%d).\n"),
GetLastError());
return 1;
}
pBuf = (LPTSTR) MapViewOfFile(hMapFile,
FILE_MAP_ALL_ACCESS,
0,
0,
BUF_SIZE);
if (pBuf == NULL)
{
_tprintf(TEXT("Could not map view of file (%d).\n"),
GetLastError());
CloseHandle(hMapFile);
return 1;
}
MessageBox(NULL, pBuf, TEXT("Process2"), MB_OK);
UnmapViewOfFile(pBuf);
CloseHandle(hMapFile);
return 0;
}
Source : [http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx]
|
|
|
|
|
I'm baffled by this. My MD5 Hash function works in Windows XP and Windows Vista, but fails in windows 7 with an Error 87.
So I rewrote the function to use HP_HASHSIZE to properly get the size, but nothing I did on Windows 7 made a difference.
I went back to XP, modified my code with the new changes, ran it, and produced the correct hash value result.
My Triple DES works fine on Windows 7, and my DES, so I'm going to check my crypt files on Windows 7 now, and see if I can find anything.
BYTE* CA_Encryption::_create_MD5_Hash( WCHAR *pzInputW, LPDWORD dwOutput )
{
BOOL bResult = FALSE;
HCRYPTPROV hProv = 0;
HCRYPTHASH hHash = 0;
BYTE *szBuffer = NULL;
DWORD dwHashLen = 0;
int iCharA = ( WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, NULL, 0, NULL, NULL) - 1 );
char *szInputA = new char[ iCharA ];
WideCharToMultiByte( CP_UTF8, 0, pzInputW, -1, szInputA, iCharA, NULL, NULL );
DWORD dwCount = sizeof( DWORD );
DWORD dwPasswordLen = iCharA;
bResult = CryptAcquireContextW( &hProv, NULL, MS_STRONG_PROV, PROV_RSA_FULL, 0);
bResult = CryptCreateHash( hProv, CALG_MD5, 0, 0, &hHash );
bResult = CryptHashData( hHash, (BYTE*)szInputA, dwPasswordLen, 0 );
delete [] szInputA;
if(CryptGetHashParam( hHash, HP_HASHSIZE, (BYTE*)&dwHashLen, &dwCount, 0 ) ) {
if (( *dwOutput > 0 ) && ( *dwOutput < 4096)) {
szBuffer = new BYTE[dwHashLen+1];
CryptGetHashParam( hHash, HP_HASHVAL, szBuffer, &dwHashLen, 0 );
*dwOutput = dwHashLen;
szBuffer[dwHashLen] = 0;
}
else {
*dwOutput = dwHashLen+1;
szBuffer = L'\0';
}
}
else {
*dwOutput = 1;
szBuffer = new BYTE[ *dwOutput ];
szBuffer[ 0 ] = L'\0';
}
CryptDestroyHash(hHash);
CryptReleaseContext(hProv, 0);
return szBuffer;
}
|
|
|
|
|
Well I guess it wasn't a Windows 7 issue, I used the power of checking the error codes, and some real hard critical thinking to figure out that on a fresh OS install, I had to generate a new key for the first time, and then after that, it works fine.
The code below was experimental, and needs to be cleaned up.
bResult = CryptAcquireContext( &hProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, 0 );
dwErrorCode = GetLastError();
if ( dwErrorCode == 2148073494 ) {
bResult = CryptAcquireContext( &hProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_NEWKEYSET );
dwErrorCode = GetLastError();
}
|
|
|
|
|
If I want to catch all the exception in the application?
|
|
|
|
|
You could put it in your main routine around all the calls to subroutines, but that is generally not a good idea. Much better to use it around specific areas where you know that an exception can occur, and you can then post specific information about it, or even attempt a recovery process.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
I know that is a way.
But if need catch all the exception in the application how to do ?
|
|
|
|
|
yu-jian wrote: But if need catch all the exception in the application how to do ?
In the main function, however there still some exception or hazards which cannot be caught! review/find them on google!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I already told you: in the main function, so it surrounds all other function calls.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
All exception in application?
If you are worried about exception cause and details of it you should set up independent try catch blocks on the exception-likely part of the codes.
Mind you, not all part of the code blocks require a try-catch.
For example:
functionx()
{
int x = 0;
}
but this one needs
functionxy()
{
x = x/y;
}
And I usually prefer wrapping the exception blocks on the top most layers for ex:
Funct1()
{
try
{
funct2();
}
}
funct2()
{
}
But if care the least about exception details and want to have a global catch of the thrown ones,
Refer: Termnial Handlers on Windows.
|
|
|
|
|
|
I'm going to go contrary to Richard's advice here...
With a few exceptions (pardon the pun) exceptions in C++ should only be thrown when your code's going down in flames and there's no chance of recovery. This means that the only place you catch exceptions is around main. This means that your program dies cleanly after telling the user and programmer what's going on and releasing all its resources.
Having said that not everyone follows those rules. If you know a subsystem chucks exceptions out instead of error codes then write an exception eating wrapper around the subsystem and convert the exceptions to return codes.
Another place you have to use exceptions is around call backs into the OS. Don't let an exception fall into a OS hole or it may be fatal to the called app. This includes thread functions and window procedures.
Cheers,
Ash
|
|
|
|
|
I need to control the audio output of the left and right channel of speakers separately, I want to use one function to give the sound to Left channel and another for the right channel.
I am still new to programming, any help would be appreciated.
|
|
|
|
|
Read up on "mixer". That is MS common "device" for controlling variety of inputs , including audio.
Good luck.
Vaclav
|
|
|
|
|
How to change the background color of Edit control or combo box only when some one has edited the text of text box or change the slection of combo box?
Thanks in advance
asdasdadadasd
|
|
|
|
|
Background colors of controls are changed by handling the WM_CTLCOLOR message and returning a brush with the required color.
In your case, you also need to check the text in the control and only then return the brush.
You would also need to invalidate the control as soon as the edit text or combo selection is changed so that the WM_CTLCOLOR handler gets called.
|
|
|
|
|
hello guys... I am having a debug assertion when trying to use forward class declaration. Basically I have this CMyTabCtrl inwhich I have forward declared two dialog class, like this:
CMyTabCtrl.h
class CTabOneDlg;
class CTabTwoDlg;
And now in the implementaion file, I am using these pointers to create instances of two dialogs and add them to the TabCtrl.
Here are the constructor and the InitializeTabs() functions.
CMyTabCtrl.cpp
CMyTabCtrl::CMyTabCtrl()
{
m_arrTabs[0] = new CTabOneDlg;
m_arrTabs[1] = new CTabTwoDlg;
m_tabOne = (CTabOneDlg*)m_arrTabs[0];
m_tabTwo = (CTabTwoDlg*)m_arrTabs[1];
}
coid CMyTabCtrl::InitializeTabs()
{
this->InsertItem(0, _T("Faculty"));
this->InsertItem(1, _T("Admin"));
m_arrTabs[0]->Create(IDD_TAB1_DLG, this);
m_arrTabs[1]->Create(IDD_TAB2_DLG, this);
m_arrTabs[0]->ShowWindow(SW_SHOW);
m_arrTabs[1]->ShowWindow(SW_HIDE);
}
And finally when in MainDialogDlg.cpp, I try to forward declare this CMyTabCtrl class, it gives debug assertion on the second line of the InitializeTabs() function.
CMainDialogDlg.h
class CMyTabCtrl;
CMyTabCtrl *tabCtrl;
CMainDialogDlg.cpp
BOOL CMainDialogDlg::OnInitDialog()
{
tabCtrl = new CMyTabCtrl;
tabCtrl->InitizlizeTabs();
}
The debug assertion it gives is as follows
mfc100ud.dll!CTabCtrl::InsertItem(int nItem, const wchar_t * lpszItem) Line 570 + 0x2d bytes C++
Why it is giving debug assertion on the InsertItem() function in the InitializeTabs() function. Thanks for at least giving time to read it.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
In which files have you #included the tab dialog and tab control headers?
|
|
|
|
|
Tab Dialog are #included in CMyTabCtrl.cpp like this
CMyTabCtrl.h
class CTabOneDlg;
class CTabTwoDlg;
CMyTabCtrl.cpp (Constructor)
m_arrTabs[0] = new CTabOneDlg;
m_arrTabs[1] = new CTabTwoDlg;
While the class for Tab control is #included in main dialog like this.
CMainDialogDlg.h
class CMyTabCtrl;
public:
CMyTabCtrl *tabCtrl;
CMainDialogDlg.cpp (OnInitDialog)
tabCtrl = new CMyTabCtrl;
tabCtrl->InitizlizeTabs();
BTW, this application works fine if I dont use forward decaration method and #include all the files, normally the way we do.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
This has nothing to do with forward declaration; that is merely a convenience for the compiler. You should look more closely at the actual code, and use your debugger to step through and try to see which variable is causing the actual assertion.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
Yes. I did exactly that. Everything works fine if I #include all the header files normally. The variable that acrually causing the problem is tabCtrl. It gives debug assertion in the second line of the InitializeTabs() function. The assertion it gives is as follows.
mfc100ud.dll!CTabCtrl::InsertItem(int nItem, const wchar_t * lpszItem) Line 570 + 0x2d bytes C++
And if you see the second line of the the said function then you will notice that it is merely inserting the tab dialog at the specified location like this
this->InsertItem(0, _T("Faculty"));
this->InsertItem(1, _T("Admin"));
So this should not be a problme I think.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Overloaded_Name wrote: It gives debug assertion
Yes, but what assertion; what is the value (or missing value) that actually causes the assertion?
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
