|
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 ?
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
