|
i did what you suggested and now the error comes out to be 00000002 (i.e The system cannot find the file specified). and the outcome of
SetDlgItemText(IDC_STAT, strng);
is "COM3:".
|
|
|
|
|
OK, so this means you fixed one problem (I think), but now came up against another. I believe 7B meant that command format was wrong that is why I was suggesting the ':' the 2 means that system cannot find COM3. Are you sure that it exists. On a Windows PC you'd look in device manager. If it really exists then 7B probably means something else.
That is about all I can help.
Henryk
|
|
|
|
|
hello guys... how do I respond to an asynchronous function call? Let's say that I have a function (asynchronous, boolean) like this
classObject->Function_Call();
Now I want to do something like this
BOOL bResult = FALSE;
bResult = classObject->Function_Call();
if(bResult)
{
}
else
Now what do I do in this situation as Function_Call() is asynchronous? Thanks for any input.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
The short answer is: you cannot do that.
When the function is asynchronous you may usually perform a test like that only to know whether the function was called properly (it might fail, for instance, if classObject was not properly initialized). To know the result of the actual function execution you should check that a state change happened, but that is specific of the function (for instance asynchrounous I/O Windows API provide GetOverallappedResult function) and there is no general way.
Veni, vidi, vici.
|
|
|
|
|
Let me address this in simpler terms without any context to the OS.
When you say "Async" , the control passes through. In your example, there is no point in waiting to check "bResult". Typically an Async function is attached with a callback function - a function pointer to notify when the operation has been completed.
Or you'll attach a Windows Handle (windows) so that the Async function can post updates to the function through messages.
So you need to figure out how your function_call() is implemented to let the main thread (for example- main()) know the completion of the function.
|
|
|
|
|
Sounds like you need a multithreaded application. With one thread set up to wait for the call while another is doing the normal processing. On the other hand it kind of depends on what you mean by asynchronous. Windows message pump is is another example of managing asynchronous events.
Cheers,
Henryk
|
|
|
|
|
Then you have to wait until you get the result and then decide how to continue.
|
|
|
|
|
I must be doing something really stupid, but... I cannot get any of the changes to my menu items reflected in visual appearance. If I check a menu item, or change string I can see changes if I test in code, but not when I click on the menu bar.
I use standard default bar creation in main frame OnCreate:
CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerWindows));
if (!m_wndMenuBar.Create(this))
{
TRACE0("Failed to create menubar\n");
return -1; }
m_wndMenuBar.SetPaneStyle(m_wndMenuBar.GetPaneStyle() | CBRS_SIZE_DYNAMIC | CBRS_TOOLTIPS | CBRS_FLYBY);
I then create a menu message handler in a view and in it I put something like this:
MENUITEMINFO info;
TCHAR buf[32];
info.cbSize=sizeof(MENUITEMINFO);
info.fMask=MIIM_STATE|MIIM_ID|MIIM_STRING;
info.fType=MFT_STRING;
info.dwTypeData=0;
HMENU hMenusafe= ((CMainFrame*)(AfxGetApp()->m_pMainWnd))->m_wndMenuBar.GetHMenu();
HMENU hMenu=::GetSubMenu(hMenusafe,0);
DWORD err=GetLastError();
int er=GetMenuItemInfo(hMenu,3,1,&info);
err=GetLastError();
info.cch++;
if( info.cch > 32)
info.cch = 32;
info.dwTypeData=buf;
er=GetMenuItemInfo(hMenu,3,1,&info);
err=GetLastError();
if(info.fState & MFS_CHECKED)
{
info.fState &=~MFS_CHECKED;
info.fState|=MFS_UNCHECKED;
_tcscpy(buf,_T("Menu is unchecked"));
info.cch=_tcslen(buf)+1;
}
else
{
info.fState &=~MFS_UNCHECKED;
info.fState |=MFS_CHECKED;
_tcscpy(buf,_T("Menu is checked"));
info.cch=_tcslen(buf)+1;
}
er=SetMenuItemInfo(hMenu,3,1,&info);
((CMainFrame*)(AfxGetApp()->m_pMainWnd))->DrawMenuBar();
As I click on the menu item I never see a check, nor changed text. However as I am stepping through the code debugging, I see that changes did take place. What am I doing wrong?
Any help appreciated
Henryk
|
|
|
|
|
|
Thanks! that works. I guess it is another disconnect in MFC  .
|
|
|
|
|
I can detect the 120 mode, now I to decide how to handle large fonts
Should I use the paint, and resize all the controls?
|
|
|
|
|
I recall reading an article once that discussed the difference between using a Frame and using a Dialog, with particular reference to the effect it had on automatically scaling the controls and parent window itself. Unfortunately, I just haven't been able to find it over the past couple of hours.
I did find a pair of article @ MS that discuss scaling, hope they'll be of some help.
How to Write High-DPI Applications[^]
INFO: Calculating The Logical Height and Point Size of a Font[^]
|
|
|
|
|
Thanks for looking for that article.
I'll start small, and fix the artwork bitmaps first. Then work on control sizes next.
I was doing final testing, and decided to check out large fonts, and found that I'm not done yet.
|
|
|
|
|
I am using the attached MSDN sample code as a base to decompress video in MJPEG format.
I can see the video frames, processed by the MJPEG driver, in capAVI preview window OK.
ICDecompressBegin return OK, but the actual data in the buffer is garbage- unchanged!
I sure could use a real sample code to get some idea what I am doing wrong.I am using OpenCV and for now I am stuck with Vfw.
Any constructive help would be appreciated.
And I did Google for it with no luck.
Thanks Vaclav
LPBITMAPINFOHEADER lbpiIn, lpbiOut;
LPVOID lpIn, lpOut;
LONG lNumFrames, lFrameNum;
// Assume lpbiIn and lpbiOut are initialized to the input and output
// format and lpIn and lpOut are pointing to the buffers.
if (ICDecompressBegin(hIC, lpbiIn, lpbiOut) == ICERR_OK)
{
for (lFrameNum = 0; lFrameNum < lNumFrames, lFrameNum++)
{
if (ICDecompress(hIC, 0, lpbiIn, lpIn, lpbiOut,
lpOut) == ICERR_OK)
{
// Frame decompressed OK so we can process it as required.
}
else
{
// Handle the decompression error that occurred.
}
}
ICDecompressEnd(hIC);
}
else
{
// Handle the error identifying an unsupported format.
}
|
|
|
|
|
My application accepts buffer (jpeg buffer) of image from another application and needs to draw that images in picture control. Buffer may be diffrrence of current image from prev image in such case I need to merge the diff with prev image buffer to draw complete image. I need to XOR diffrence buffer with prev buffer, how can I do that so that I can get only one resultant buffer.
|
|
|
|
|
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 ?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
