C / C++ / MFC Discussion Boards

lynchspawn13-May-05 1:54

13-May-05 1:54

Ah - I see what happened now.

I ran into the same problem years ago. I wasn't intentionally using different headers but by mistake ended up doing something very similar.

I'm sure someone else can give you a more detailed explanation of this but the short story is that the address of your ID is off into a bogus area due to the multiple header files.

I think if you really need to be able to do this, you need to setup some dummy variables so that both of the headers represent a class with the same layout/size. I'm still not sure if it is going to work in that case but I do know from experience that using multiple headers holding different variables will cause big problems. Sorry I can't give more/better info.

Re: DLL memory issue

Andrew Hoole13-May-05 2:39

Andrew Hoole

13-May-05 2:39

Yeah I think I am going to have to use the same header file but when I tried it earlier I get compiler errors on the

// Dialog Data<br />
	//{{AFX_DATA(CLantisPatientSelectDlg)<br />
	enum { IDD = IDD_SELECTPATDLG };<br />
		// NOTE: the ClassWizard will add data members here<br />
	//}}AFX_DATA

section of the header because that is declared in the resource.h file of the dll and not the resource.h file of the application.

Is it a problem if several of these IDs resolve to the same number?

I would have thought that the layout/size of the class would have been held in one of the compiled files that are used by the linker so something.

Re: DLL memory issue

Andrew Hoole13-May-05 2:54

Andrew Hoole

13-May-05 2:54

Ok I have now included the resource.h file in the CLantisPatientSelectDlg.h file and now the whole thing(including the important bits I had removed for debugging purposes) compiles and runs fine.

So now I just need to find out how I can use different header files without getting this trouble as it seems the only way to hide from the user all the mess of the implementation.

Thanks for all the help and comments so far.

Andrew Hoole

Re: DLL memory issue

Blake Miller13-May-05 4:03

Blake Miller

13-May-05 4:03

How to hide mess from user:

1. Implement a data structure that has the data you need to and from the dialog. Share this data structure in a header between the main program and the support DLL. Program passes pointer to valid memory block representing data structure to exported DLL function.

2. Also pass HWND of parent window into exported function. This way, your C++ object does not have to cross the DLL boundary. Wihtin the DLL you cna make a temporary CWnd and 'attach' the passed in HWnd to it. Remember to Detach ont he way out.

Now you don't have to 'expose' any more details than necessary and almost all, if not all, of your problems are solved.

The advantage here, is you can actually make your entire MFC Dialog DLL code compatible with a regular Win32 program if done correctly - static link MFC, use the proper AFX macros, etc.

Trying to export a 'fraction' of a dialog's class from the DLL will only get you into more trouble than it is worth. You are not ending up with the proper offsets to member variables, virtual functions, etc. I would stay clear of any 'cute' skinning or other 'framework' system that relies on such a method.

Re: DLL memory issue

Andrew Hoole13-May-05 5:04

Andrew Hoole

13-May-05 5:04

Are you saying that I should wrap my DLL dialog class in another class with a simple interface. Otherwise I can't see how what you are suggesting gets me away from having to have the header file of my DLL dialog exposed to the users.

Using the HWND idea - would that mean I don't create a direct instance of the DLL dialog class as I have done but rather pass the HWND into a simple function which then attachs to it and creates the dialog class internally.

Sorry I am not being very bright here but thanks for the help.

Re: DLL memory issue

Blake Miller13-May-05 6:05

Blake Miller

13-May-05 6:05

Sorry, option 2 is the one I meant.

When you pass in the HWND of the 'parent' window to the function, you attach this passed HWND to an internal CWnd object, and that CWnd can be the 'parent' for your internal dialog class. After DoModal returns and you collected up all the data, you can detach the temporary CWnd from the passed HWND.

This way, the entire interface into the DLL to 'call' the dialog is a pointer to your data structure and an HWND. You only need to give the user a header file with the definition of your data structure and a function prototpye - the function exported from your DLL.

I do this all the time to get InstallShield or legacy Win32 applications to be able to call MFC dialogs.

byte to hex string

richiemac12-May-05 23:50

richiemac

12-May-05 23:50

Hi all,

I'm a complete novice to C++.net and I'm in a spot of bother. I have some values that require certain calculations and conversions which I have no problem with at all. My problem arises when I try to store the values as hex strings. So, for example, I have a byte holding the value (in dec) 252. I want to hold the value as its hex equivalent in a string which will later be displayed in a textbox.

Does vs.net provide any built in functions for this task or, if not, how would I go about the conversion manually?

Any help gratefully recieved.

Re: byte to hex string

toxcct12-May-05 23:54

toxcct

12-May-05 23:54

char c = 252;
CString str;
str.Format("0x%X", c);

there, str contains the string "0xFC"

you could also use sprintf() and so on...

TOXCCT >>> GEII power
[toxcct][VisualCalc]

Re: byte to hex string

richiemac13-May-05 0:13

richiemac

13-May-05 0:13

I tried that already and just get the following error,

error C2664: 'System::String __gc *System::String::Format(System::String __gc *,System::Object __gc *)' : cannot convert parameter 2 from 'int' to 'System::Object __gc *'
Conversion from a built-in type or a value type to 'System::Object __gc*' requires boxing

Re: byte to hex string

toxcct13-May-05 0:51

toxcct

13-May-05 0:51

oh, your programming managed code.

well, what about this ?

char c = 252;
char str[100];
ssprintf(str, "0x%X", c);

TOXCCT >>> GEII power
[toxcct][VisualCalc]

Re: byte to hex string

richiemac13-May-05 1:37

richiemac

13-May-05 1:37

What I need to do is store the hex value as a string so I can set a textbox text element to that string. So I'm looking to do something like

 <br />
System::Byte b = 252;<br />
System::String* s = b (formatted as hex value);<br />

then

<br />
textBox1->Text = s;<br />

Does any of that make sense?? Smile | :)

Re: byte to hex string

David Crow13-May-05 2:15

David Crow

13-May-05 2:15

toxcct wrote:
ssprintf(str, "0x%X", c);

Shouldn't that be:

sprintf(str, "%#X", c);

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

Re: byte to hex string

toxcct13-May-05 2:20

toxcct

13-May-05 2:20

for ssprintf -> sprintf, yes, i made a mistake

for 0x%X -> %#X, it is as you prefer...

TOXCCT >>> GEII power
[toxcct][VisualCalc]

Re: byte to hex string

itkid13-May-05 1:47

itkid

13-May-05 1:47

Hi Dear,
Just do the following
byte _val;
char _data[4]="";
sscanf(_data,"%x",&_val);

Regards
~Kid

Re: byte to hex string

David Crow13-May-05 2:19

David Crow

13-May-05 2:19

itkid wrote:
sscanf(_data,"%x",&_val);

Perhaps you meant sprintf() instead of sscanf().

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

Re: byte to hex string

richiemac13-May-05 3:18

richiemac

13-May-05 3:18

Sorry still not working, getting the following,

error C3861: 'sprintf': identifier not found, even with argument-dependent lookup

if I use sscanf, same error with obvious replacements.

Re: byte to hex string

David Crow13-May-05 3:26

David Crow

13-May-05 3:26

The sprintf() function is part of stdio.h. I do not know if that set of APIs is available with VS.Net.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

Re: byte to hex string

richiemac13-May-05 4:02

richiemac

13-May-05 4:02

Can't seem to get it to work at all tbh. But eh, what do I know? Smile | :)

Surely .net must provide some way to format a string to dispay value in hex. Or you would think so!!

Re: byte to hex string

toxcct13-May-05 4:14

toxcct

13-May-05 4:14

ask this in the Managed C++ forum[^] instead so...

TOXCCT >>> GEII power
[toxcct][VisualCalc]

Re: byte to hex string

David Crow13-May-05 4:21

David Crow

13-May-05 4:21

Christian Graus might have a few articles in this regard.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

Re: byte to hex string

richiemac13-May-05 4:26

richiemac

13-May-05 4:26

I'll give it a go.

Cheers everyone for the help!

CMap lookup

rgchezhian12-May-05 23:19

rgchezhian

12-May-05 23:19

Hi,

I have to create a CMap and store N number of (CString,int)
and i want to look up using CString and return value would be int.

If any body have gone through this requirement pls let me know.
i am new to CMap.If anyother method exist also welcome.

regards
Chezhian

Re: CMap lookup

Jack Puppy13-May-05 0:49

Jack Puppy

13-May-05 0:49

<br />
#include <afxtempl.h><br />
<br />
CMap<CString, LPCTSTR, int, int> myMap;<br />
<br />
myMap.SetAt("one", 1);<br />
myMap.SetAt("two", 2);<br />
myMap.SetAt("three", 3);<br />
<br />
int nValue = 0;<br />
if (myMap.Lookup("two", nValue))<br />
{<br />
    TRACE(_T("value is %d\n"), nValue);<br />
}<br />

Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!

Re: CMap lookup

rgchezhian13-May-05 1:59

rgchezhian

13-May-05 1:59

hi,

I tried this.

It gives the following errors

'myMap':UnKnown size
'myMap':Cannot be destroyed
'CMap':no appropriate default constructor available

Is any header has to include for this.

I am using vc++ 7.1 version?

Regards
Chezhian

Re: CMap lookup

David Crow13-May-05 2:21

David Crow

13-May-05 2:21

rgchezhian wrote:
Is any header has to include for this.

How about afxtempl.h.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.