C / C++ / MFC

Llasus31-Oct-07 17:52

Llasus

31-Oct-07 17:52

you can use the %x to put it in the CString variable. Ex. message.Format("%x",HexPrepend[0])

chandu00431-Oct-07 19:02

chandu004

31-Oct-07 19:02

Larrson12 wrote:
So in memory result should be:

0102030448656C6C6F

thats fine,
but what memory are you referring to here.
if it is the CStrings memory, based on what Llasus has suggested, here is the clearer version.
message.Format("%02x%02x%02x%02x%s",HexPrepend[0],HexPrepend[1],HexPrepend[2],HexPrepend[3],mesage);

is that what you are exactly looking for?
Gud Luck.

--------------------------------------------
Suggestion to the members:
Please prefix your main thread subject with [SOLVED] if it is solved.
thanks.
chandu.

Naveen31-Oct-07 20:44

Naveen

31-Oct-07 20:44

if you change the unsigned char to simply char, the below mehod will be easy.

CString message = _T("Hello");<br />
unsigned char HexPrepend[] = { 0x01, 0x02, 0x03, 0x4 };<br />
CString csNewMsg( HexPrepend, 4 );// You should specify 4 here because, only 4 characters need to be copied from the HexPrepend. other wise it will try to copy the charaters untill it finds a null character.<br />
csNewMsg += message;

CString message = _T("Hello");<br />
unsigned char HexPrepend[] = { 0x01, 0x02, 0x03, 0x4 };<br />
TCHAR tcMsg[100];<br />
memcpy( tcMsg, HexPrepend, 4 );<br />
memcpy( tcMsg + 4, message.operator LPCTSTR(), 5 );

nave

[OpenedFileFinder]

Larrson1231-Oct-07 23:21

Larrson12

31-Oct-07 23:21

Hi all,

First method given by Naveen.R with char only is perfect for me.

Thank you all for time.

Regards.
L.

what does GetKeyState(VK_SHIFT) & 0x8000 mean? [modified]

John R. Shaw31-Oct-07 22:46

John R. Shaw

31-Oct-07 22:46

You are joking right! No!

Well if you know the size of the array as shown then:

CString message;
message.Format("%s%x%x%x%x","Hello", HexPrepend[0], HexPrepend[1], HexPrepend[2], HexPrepend[3]);

That’s bad C++ (MS thing), but good C.

I could give u a dozen other examples, but I am not in the mood and a little research (very little) will answer your question.

INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra

fantasy121531-Oct-07 17:25

fantasy1215

31-Oct-07 17:25

Whenever I come here to post a question or see your discussion, I click the homepage POST A QUESTION to come here, Is there any more easy way to come to the question board?
BELOW is my question too.
what does this mean?

<br />
if (GetKeyState(VK_SHIFT) & 0x8000)<br />
{<br />
}<br />

ACTUALLY 2 questions.

-- modified at 0:35 Thursday 1st November, 2007

Roger Broomfield31-Oct-07 18:58

Roger Broomfield

31-Oct-07 18:58

Well personally I have this shortcut[^] on my local homepage.

GetKeyState(...) returns a short, if the requested key is down then the high order bit is 1, so by masking the returned short with 0x8000 the result tested by if will be zero if the key is up and non-zero if the key is down ignoring all the bits which you dont care about because you only want to know if the shift key is down.

Nishad S31-Oct-07 18:59

Nishad S

31-Oct-07 18:59

fantasy1215 wrote:
if (GetKeyState(VK_SHIFT) & 0x8000)

Means the key should be kept pressed.

- NS -

fantasy121531-Oct-07 20:30

fantasy1215

31-Oct-07 20:30

Then does this code means clearly?

<br />
BOOL bShiftKeyDown = GetKeyState(VK_SHIFT) < 0;<br />
if (bShiftKeyDown)<br />
{<br />
}<br />

thx you all, I understand GetKeyState more clearly.

Nishad S31-Oct-07 20:34

Nishad S

31-Oct-07 20:34

May be...

But actually the bit is checked there. Not simply its value. You will understand it clear from MSDN documentation regarding this. See this...

Return Value

The return value specifies the status of the specified virtual key, as follows:

. If the high-order bit is 1, the key is down; otherwise, it is up.
. If the low-order bit is 1, the key is toggled. A key, such as the CAPS LOCK key, is toggled if it is turned on. The key is off and untoggled if the low-order bit is 0. A toggle key's indicator light (if any) on the keyboard will be on when the key is toggled, and off when the key is untoggled.

- NS -

Loading .Net DLL in MFC application problem

JudyL_MD1-Nov-07 2:45

JudyL_MD

1-Nov-07 2:45

The high-order bit (0x8000) is the sign bit in a short variable. If it is on, then the value is < 0. This does the same thing as the code you posted earlier - it's just not as clear in this case. The earlier one would be preferable, IMHO, since it is obvious that you are testing for the state of the high-order bit.

Judy

Wolfram Steinke31-Oct-07 16:04

31-Oct-07 16:04

I have been given a .NET Dll which I have to intergrate into and MFC solution. It sort of worked when I added it to Microsoft sample MFC04.exe sample, and imported it into one of it's Dlls. It gave a problem with passing strings to the MFC code but that should be easy to overcome.
Creating a new project in the existing solution with the same settings first gave build error with unresolved external (the lib file never was built).
Finally it builds but at runtime I get this:

Debugger:: An unhandled non-continuable exception was thrown during process load
The program '[2436] AppMgr.exe: Native' has exited with code -1073741511 (0xc0000139).

Any assistance, suggestions to get round this would be most welcome.

Happy programming!!

Prasann Mayekar1-Nov-07 2:36

Prasann Mayekar

1-Nov-07 2:36

do u use

#using <dllname>
using namespace <dllname>

and then compiling with clr option?

calling .net dll from mfc dll has a mixed dll loading problem. but works if u use in a mfc app.

Prasann

Prasann Mayekar1-Nov-07 2:38

Prasann Mayekar

1-Nov-07 2:38

i mean

#using dllname
using namespace dllname

Mark Salsbery1-Nov-07 6:09

Mark Salsbery

1-Nov-07 6:09

What is the lib file you refer to?

Dynamically linking a .NET assembly has nothing to do
with a lib file.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Wolfram Steinke1-Nov-07 10:56

1-Nov-07 10:56

That's interesting, cause the Microsoft example generates a lib for ".NET/MFC interface" Dll and links with it. The interface Dll uses the namespace for the .NET, yes, and that part works when I add it to the Microsoft sample. That Dll (Which is an MCF extension) then exports a C/C++ function which accesses the .NET dll.
The error I'm getting now seems to be to with initialization when the dll is being loaded. It is trying to initialize both the managed and unmanaged code at the same time, and this is apparently a no-no.

How can I get around this? It's much work to work to rewrite the umpteen other files in the solution.

Happy programming!!

Mark Salsbery1-Nov-07 11:27

Mark Salsbery

1-Nov-07 11:27

So it's a mixed-mode DLL, not a pure .NET DLL?

Or is there another DLL involved between a .NET assembly and the MFC app?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Wolfram Steinke1-Nov-07 12:33

1-Nov-07 12:33

Yes it's the mixed mode dll I'm getting something wrong in.
No there is an MFC dll accesing the Mixed mode dll which in turn accesses the .NET assembly.

Happy programming!!

Mark Salsbery1-Nov-07 13:01

Mark Salsbery

1-Nov-07 13:01

Ok, I think I'm following now Smile | :)

I would first make sure that you're following all the rules
for an MFC extension DLL, as explained here:

Extension DLLs[^]
Initializing Extension DLLs[^]

You should be able to link the app to the extension DLL (both the static link to the lib
file at build time and the dynamic link at runtime) with no errors.

Once you have that, the .NET DLL should be much simpler, since that linking
is done by the assembly loader.

If you still have the problem, it could be a loader-lock issue.

Are you making any calls besides the required MFC initialization (as described in the
links above) in your extension DLLs DllMain()? If so, I would comment those out and
test - that's where most DLL load problems occur.

Global/static variables can be a problem as well.

That's all I can think of off hand. If you still get the error, can you post
the contents of your debugger output window?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Wolfram Steinke1-Nov-07 14:26

1-Nov-07 14:26

Something else I have observed that confuses me is when I select the mixed mode dll as a dependency in the MFC dll it's lib is automatically added to the linker command line. However once I selected /clr on the mixed mode dll that command line entry is automatically removed and causes unresolved externals. In the MS sample this does not seem to be case.

I'm therefore thinking that my problems are to do with compiler/linker settings.

If I start with the mixed mode dll as a pure MFC extension it works fine both implicit and explicitly linked at runtime.

as soon as I add the /clr flag the problems start, before I even add the .NET dll to the references.

Happy programming!!

Wolfram Steinke8-Nov-07 11:35