|
I'd use Spy++ to check just what messages are being sent when the selection changes manually. In order to save doign refreshes so often, maybe the dialog waits for a CBN_CLOSEUP notification message to be sent? Maybe sending CB_SETCURSEL (which you are doing) does not then send a CBN_SELCHANGE notification. After all, why should it? You just changed it yourself!
This is a very dated control we're talking about, and every optimisation under the sun was used to make it perky on 386s (remember windows 3?) and then kept for compatibility.
Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
|
|
|
|
|
Yes I looked in Spy++, normally there is sent:
message:0xC06F (Registered:"commdlg_LBSelChangedNotify") wParan:0000470 lParam:00000000
where wParam is simply the ID of cmb1 and lParam the new selected filter ID.
So I tried simply also to send this afterwards using:
SendMessage(0xc06f, cmb1, 1);
But it seems it doesn't work, also if I see this message now also in Spy++
|
|
|
|
|
That's curious... because LBN_SELCHANGE is 1 in my header files, as is CBN_SELCHANGE...
In a "normal" window, the message arrives as follows:
uMsg = WM_COMMAND (which is 0x111...)
High word of wParam = 1, lo word is control ID, so 0x470 doesn't fit that pattern...
So this is not a classic control at all! All bets are off for my answer then, sadly...
Using a registered message is a bit of a hint.
One thought... Being a registered message, that value of 0xc06f may not work between runs of your software. (It *probably* will, but you can't rely on it). So get the message from
UINT m_CustomNotify = RegisterWindowMessage (_T("commdlg_LBSelChangedNotify"));
instead of using a hard coded value.
Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
|
|
|
|
|
hm it's derived dialog but rather standard anyway. Maybe this is depends on OFN_EXPLORER flag is set or not? At least I read it might behave differently then...
Now I used
SendDlgItemMessageA(wndDlg->m_hWnd, cmb1, CB_SETCURSEL, mSelectedFilterID - 1, 0);
SendMessageA(wndDlg->m_hWnd, WM_COMMAND, MAKEWPARAM(cmb1, CBN_SELCHANGE), (LPARAM)wndDlg->GetDlgItem(cmb1));
The control updated but the view still not, so it's seems similar like direct call of SetCurSel
|
|
|
|
|
I solved it! I had to send CBN_SELENDOK instead of CBN_SELCHANGE message...then it worked...
|
|
|
|
|
hi.
i create a new windows forms application project in visual c++.net2005 and add necessary lib and header files.
and in Form1.h ,add this code:
#pragma once
#include "mclmcr.h"
#include "foo2lib.h"
and i do no change in code.
when i compile this solution .it give me 12 errors.and all of them are "redefinition; different type modifiers":
for example :
Error 1 error C2373: 'matGetDir_proxy' : redefinition; different type modifiers E:\Program Files\MATLAB\R2008a\extern\include\mclmcrrt.h 143
.
.
.
but when i create a new win32 console application project and do same workes,compiler give me no error
and solution is run.
please help me to remove these errors.
|
|
|
|
|
I have a structure in C# which is read using a BinaryReader like so:
binaryReader.ReadInt32();
binaryReader.ReadInt32();
binaryReader.ReadString();
binaryReader.ReadString();
I need to be able to send this structure from a C++ app, I have managed to send across the two ints and I realise that the strings have a length marker in front of them but I cannot get it to send the string.
I am currently using a struct like this:
struct MyData
{
int val1;
int val2;
int strLength1;
LPCTSTR string1;
int strLength2;
LPCTSTR string2;
};
This send the ints fine but I get 2 0 length strings.
What am I doing wrong?
|
|
|
|
|
One way that works AFAIK is using fixed-length strings, put them in length+chararray on the C/C++ side
and in length+array on the managed side, using some Marshal attribute to indicate that the
array data has to be there, not just a reference.
It is something like [MarshalAs(UnmanagedType.ByValArray, SizeConst=16)]
BTW: as always, be wary of different character types.
|
|
|
|
|
At a guess I'd day you need two short s for your string lengths or possibly even two BYTE s. If C# strings are a development of BSTRs then I doubt the string lengths will be as much as the 4 bytes you get with an int . 4GB long strings are really not what MS want to be supporting I guess. The other thing is you need the character data itself effectively in the structure rather than pointers to the characters (LPCTSTR).
You want something like this.
<br />
struct MyData<br />
{<br />
int val1;<br />
int val2;<br />
unsigned short strLength1;<br />
TCHAR string1[strLength1];<br />
unsigned short strLength2;<br />
TCHAR string2[strLength2];<br />
};<br />
but of course you can't do that directly as strLength1 and strLength2 are not known at compile time. This means you're likely going to have to use some form of serialization/deserilaization rather then just passing a structure unless you can use fixed length strings.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks, I thought I would end up doing some serialization. I have checked the BinaryWriter documentation and it states
This method first writes the length of the string as a four-byte unsigned integer, and then writes that many characters to the stream. This method writes a length-prefixed string to this stream using the BinaryWriter instance's current Encoding.
So it seems it does need a 4-bytes uint to prefix the length. So my next question is how would I create a byte array containing the strings and the lengths? (C++ is not my strong point!), I know how to create the array using malloc and copy the strings in but not the ints.
|
|
|
|
|
Yep, I'd say a malloc, or more properly, BYTE* pBuffer = new BYTE[uBufferSize]; is the way to go.
Once you've got your buffer you write the strings in by casting a copy of pBuffer + n to a TCHAR* and
copy your ints in by casting pBuffer + n to an int* and setting its value.
<br />
int* pFirstInt = reinterpret_cast<int*>(pBuffer + 0);<br />
*pFirstInt = nValue;<br />
int* pSecondInt = reinterpret_cast<int*>(pBuffer + 4);<br />
*SecondInt = nValue2;<br />
It's not pretty but then this sort of stuff seldom is. You could create some struct types and cast to
those. Up to you really. There are almost certainly fancier ways to do this with operator << overloading
and stl string stream modifiers but I wouldn't go there unless you've got a lot of complex data to
transfer and you know your stl.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks for the tip, that worked for the ints perfectly but still not getting the strings.
My code now is:
int* pFirstValue = reinterpret_cast<int*>(pBuffer + 0);
int* pSecondValue = reinterpret_cast<int*>(pBuffer + 4);
unsigned int* pStringLength1 = reinterpret_cast<unsigned>(pBuffer + 8);
unsigned int* pStringLength2 = reinterpret_cast<unsigned>(pBuffer + 12 + (sizeof(WCHAR) * firststring));
*pFirstValue = 1;
*pSecondValue = 2;
*pStringLength1 = strlen(firststring);
*pStringLength2 = strlen(secondstring);
strcpy((char*)(pBuffer + 12), firststring);
strcpy((char*)(pBuffer + 16 + (sizeof(WCHAR) * firststring)), secondstring);
</unsigned></unsigned>
That appears to me to be correct but as I've said before, C++ is not my strong point. Does that look correct?
|
|
|
|
|
This won't solve your marshaling problem, but:
You can't use strcpy, or TCHAR. All your strings are wchar_t
in C# so you should be using only wide character functions and types.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hello my dear friends,
I have developed a code to analyze a file (huge size). My application is MFC Dialog based. I use CFiledialog to open the files, after selecting the files I click OK and after that a shadow is appearing on my dialog for the size of the CFiledialog. This is very distraction to the GUI I have developed. Is there any way to remove the shadow after selecting the file.
Code is :
CString Test::OpenFile()
{
CString fname=LPCTSTR("");
CFileDialog fileDlg(TRUE, _T (".dat"),NULL,OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST, _T ("Data File (*.dat)|*.dat|Data File (*.dat)|*.dat|"),this);
if(fileDlg.DoModal()==IDOK)
{
fname = fileDlg.GetPathName();
}
else
{
MessageBox(TEXT("Select the File"));
}
return fname;
}
Please advice. Many thanks in advance.
|
|
|
|
|
|
I don't see any problem in the code you've provided. Probably you must try to do that "huge processing" in a worker thread and see if that helps.
|
|
|
|
|
You could try using Invalidate(); UpdateWindow(); on your dialog
after the call to fileDlg.DoModal() but before you do any lengthy
processing on the UI thread (which you shouldn't be doing anyway).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi, Did you resolve this issue if yes please let me know how it worked.
Thanks
|
|
|
|
|
Hi,
how to conver char* into BYTE* in C++
Regards
|
|
|
|
|
Short (and dangerous) answer: with a cast, for instance
char * myCharPointer ="hello";
BYTE * myBytePointer = (BYTE *) myCharPointer;
A better answer may follow a more detailed request.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
of course, you're looking for devil every where :p
a char* is not always a string
char c = 'c';
char* pc = &c;
BYTE* pb1 = (BYTE*)pc;
BYTE* pb2 = reinterpret_cast<BYTE*>(pc);
BTW, looking at the level of the question, i think it's worth saying that a char IS a BYTE :
char c = 'c';
BYTE b = c;
|
|
|
|
|
toxcct wrote: a char* is not always a string
char* is never a string.
|
|
|
|
|
what do you know about C++, you Mr univoter ?
|
|
|
|
|
nice arguments
|
|
|
|
|
toxcct wrote: of course, you're looking for devil every where [Poke tongue]
of course.
toxcct wrote: BTW, looking at the level of the question, i think it's worth saying that a char IS a BYTE:
Nope. As you know (I know that you know ), char is a signed integer ranging from -128 to 127 , while a BYTE is an unsigned integer ranging from 0 to 255 .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|