|
|
thanks, I got it working.
|
|
|
|
|
Can anyone help me in my C++ course?
|
|
|
|
|
|
|
Are you female and cute? 
Just kidding, but when I was back in engineering school a *very* long time ago, that never hurt.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I have a CDialog derived dialog which has a CFormView derived member which has a number of CEdit derived controls placed on it.
Based on business rules at runtime one of the CEdit derived controls should receive the focus when the dialog is displayed. In the OnInitialUpdate override of the CFormView derived class the specfic control is determined and focus is set to that control with the following call:
PostMessage(WM_NEXTDLGCTL, (WPARAM)pFocusEdit->GetSafeHwnd(), TRUE);
When the dialog is displayed there is no caret displayed within the control. It is outlined in the blue colour showing that it has focus, if I start typing the text is displayed but still no caret. If I TAB to the next control the caret is displayed there and if I TAB back it is now displayed in the originally focused control.
Alternatively, after the dialog is initially displayed and the caret is not showing If I shift the active window to another app (e.g. visual studio) and then actiavte the app again then the caret does appear in the CEdit control.
Any suggestions as to how I can ensure that the desired CEdit control receives focus on display of the dialog and that the caret is displayed?
Thanks,
|
|
|
|
|
|
Richard MacCutchan wrote: You should use the OnInitDialog method of CDialog Class | Microsoft Docs[^] to set the focus.
I stated that the focus edit is being set from the OnInitialUpdate override of the CFormView derived class, I should have clarified that this has been called from the CDialog OnInitDialog method via a call to
SendMessageToDescendants(WM_INITIALUPDATE, 0, 0, TRUE, TRUE);
Also, the OnInitDialog method returns FALSE to indicate that I have set the focus to a control.
.
|
|
|
|
|
Sorry, I cannot help further as I don't have MFC.
|
|
|
|
|
Is it possible to somehow check during compile time if an enum exists, i.e. something like this:
typedef enum {
MY_ENUM_VALUE = 0
} myEnum_e;
#define DOES_ENUM_EXIT(__ARG__) ??? What goes here???
if (DOES_ENUM_EXIT(myEnum)) {
}I know that I could achieve something similar easily be using
#define MY_ENUM_VALUE (0)
instead, but then my code wouldn't be type safe.
|
|
|
|
|
|
No, because the #define statement is handled by the preprocessor, and the enum value is not known until it is fed into the compiler, which comes later.
|
|
|
|
|
|
|
I have written a little piece of code to read few (first 512) bytes from USB drive. here is the code:
HANDLE hVolume = ::CreateFile(sVolume, GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL);
TRACE("Volume handle: %p\n", hVolume);
LONG lDistLow = 0;
PLONG plDistHigh = 0;
if (INVALID_SET_FILE_POINTER == SetFilePointer(hVolume, lDistLow, plDistHigh, FILE_BEGIN) &&
NO_ERROR != GetLastError())
{
TRACE("Error: %d\n", GetLastError());
return FALSE;
}
else
{
TRACE("%d\t%d\n", lDistLow, plDistHigh);
}
DWORD dwLen = 512;
DWORD dwNum = 0;
void* pBuffer = NULL;
ReadFile(hVolume, pBuffer, dwLen, &dwNum, NULL);
TRACE("%p\t%d\t%d\n", pBuffer, dwLen, dwNum);
but the result is:
Volume handle: 00000438
0 0
00000000 512 0
this pBuffer NULL tell me that I am not able to read that sectors ... why ? The program is running as admin and sVolume is feed by _T("\\\\.\\F:"), first TRACE macro printed is a prove that is OK that part. SetFilePointer is used to position the reading part, and I intend to setup offset to the beginning, right ?
|
|
|
|
|
What does ReadFile return? TRUE or FALSE?
|
|
|
|
|
The ReadFile function returned FALSE, which tell me that reading has failed.
|
|
|
|
|
In this case you have to call GetLastError to obtain the exact reason of the failure!
|
|
|
|
|
I didn't feed correctly the buffer. After I setup correctly that parameter, ReadFile return TRUE.
|
|
|
|
|
Your pBuffer value is NULL, so you are trying to read data into the memory address 0 - you have to allocate some space to read the data into and use that for your pBuffer value. For 512 bytes a stack-based array should do the trick.
|
|
|
|
|
_Flaviu wrote: pBuffer NULL tell me that I am not able to read that sectors
No, pBuffer = NULL; tells you that you have not allocated any space to pBuffer. And don't use void* unless you are trying to allocate nothing.
You can allocate space either of the following ways.
unsigned char* pBuffer = new unsigned char[dwLen]; unsigned char buffer[dwLen]; ReadFile(hVolume, buffer, dwLen, &dwNum, NULL);
|
|
|
|
|
Is not accepted:
unsigned char buffer[dwLen];
Of course, putting 512 is ok, but I need to allocate that length of buffer through a variable.
I prefer this option, on stack, as far as I know, is faster than heap.
|
|
|
|
|
You can fix that easily by doing it this way:
#define SECTOR_SIZE 512
DWORD dwLen = SECTOR_SIZE;
DWORD dwNum = 0;
char buffer[SECTOR_SIZE];
ReadFile(hVolume, buffer, dwLen, &dwNum, NULL);
If you are using C++ then instead of #define you can use this:
const int SECTOR_SIZE = 512
|
|
|
|
|
Good idea. I have tried in this way:
CByteArray arrByte;
arrByte.SetSize(512);
BOOL bRet = ReadFile(hVolume, arrByte.GetData(), dwLen, &dwNum, NULL);
and seem to go well.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
