C / C++ / MFC

10-Apr-06 18:21

You can't specify a binary literal directly. Specify it as octal or hex instead.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Variable Help

borono10-Apr-06 14:14

borono

10-Apr-06 14:14

hey, trying to send a DLL written in C with VC6, an integer from a VB6 app. I send it as an integer, it arrives as a u_int and is always 0. I accept the integer using a function, not a callback. I tried sending the value as a string and atoi()ing it, same results. I sprintfed the value and MessageBoxed it, which is how I know it is always 0 before usage.

How do I make the value keep its value when sent from VB6 app to VC6 DLL?

If you need more info, code or something, let me know. Thanks in advance.

Joshua Quick10-Apr-06 15:43

Joshua Quick

10-Apr-06 15:43

Here's a tip.
In VB6, Integers are 16 bit and Longs are 32 bit.
You'll need to map a VB6 Long to a C/C++ int.

-- modified at 23:22 Monday 10th April, 2006

borono10-Apr-06 17:30

borono

10-Apr-06 17:30

Should I do that on the C side? I assume you mean to send the long value to the DLL function and do the conversion there. Can't find any info on how to make that conversion on the VB side, which I guess wouldn't make sense and would be redundant to do so. Let me know if I am headed in the right direction. I will continue to research it and check back here periodically. thanks in advance.

Joshua Quick10-Apr-06 17:49

Joshua Quick

10-Apr-06 17:49

This isn't really a conversion issue. This is an issue with correctly defining the C function on VB6's side.

I suggest that you leave your C library alone (assuming it has worked fine before). Instead, you should fix the Declares in your VB6 code.
If the C function has a short, use an Integer type in VB6.
If the C function has an int, use a Long in VB6.

For example, if a C function is defined like this...
int Sum(short x, short y);

Then in VB6, it would be declared like this...
Private Declare Function Sum Lib "YourLib.dll" (ByVal x As Integer, ByVal y As Integer) As Long

borono11-Apr-06 10:43

borono

11-Apr-06 10:43

hey, sorry for the late reply. I did what you suggested and it is now returning the proper integer on the C DLL side, but when it goes into my processing function, the value becomes 0 still. I should probably have told you that the processing function is created in its own thread --maybe that is why I am having trouble.

Basically the VB6 app sends the integer as long, it is recieved by a function and stored as u_int. The function calls the threaded function and the value should then be used in a for loop to determine how many times the for loop should loop.

Theo:

u_int *My_Var;

<Threaded_Function>

<for 0 to My_Var> //variable = value sent from vb app (i.e., 0 - infinity).
//do processing code
</for>

</Threaded_Funtion>

<function u_int *Sent_Variable>
myVar = Sent_Variable;
return 0;
</function>

So, that is pretty much it. Let me know if you need more info. Thanks in advance.

Overloads resolution crazyness ?

Joshua Quick11-Apr-06 12:05

Joshua Quick

11-Apr-06 12:05

This sounds like an issue in your C library.

For starters, you might just want to comment out your C function's code and just have it return a constant. This will prove whether or not a call to your C library is working.

Next, I think you need to debug your C function's code because I suspect that's where the issue is. If you're using threads, then you could be running into race conditions.

If your C function makes a call to a threaded function, are you blocking the current thread while it's being processed? Otherwise the current thread will just fall through before the process completes (or even begins). Or are you making a separate call to your C library for the process result?

CTreeCtrl checkboxes

CodeGoose10-Apr-06 11:34

CodeGoose

10-Apr-06 11:34

Is it possible to have a tree control with some items having checkboxes and others not?
ie) the root items to not have checkboxes, but the child items to have a checkbox.

Marcello10-Apr-06 11:29

Marcello

10-Apr-06 11:29

Hello,
a question around the error C2666, under vc80 (RTM-8.0.50727.4200)
Is it compliant to the C++ standard ?

class CondParams
{
...

 static bool getVariableState( const string& s, int& idx, string::size_type* p = NULL; // A
 static bool getVariableState( string& rs, int& idxVar, const bool& trim ); // B

);


bool CondParams::getVariableState( string& rs, int& idx, const bool& trim )
{
...
	VCF::String::size_type p = 0;
	bool ok = getVariableState( rs, idx, &p );
	if ( ok ) rs = rs.substr( p );
...
}

I get the error message:
1>d:\projs\condparams.cpp(66) : error C2666: 'vcfex::CondParams::getVariableState' : 2 overloads have similar conversions
1> d:\projs\code\condparams.h(130): could be 'bool vcfex::CondParams::getVariableState(string &,int &,const bool &)'
1> d:\projs\code\condparams.h(129): or 'bool vcfex::CondParams::getVariableState(const string &,int &,string::size_type *)'
1> while trying to match the argument list '(string, int, size_type *)'
1> note: qualification adjustment (const/volatile) may be causing the ambiguity

I could fix the problem by doing:
1) static bool getVariableState( string& s, int& idx, string::size_type* p = NULL; // A
or by doing:
2) bool ok = getVariableState( const_cast<const string="">(rs), idx, &p );
so I guess that the compiler is confused because it doesn't find any perfect match.

The solution 1 is usually not acceptable.
So I have to apply 2).
But this situation is *very* common: why should I need to specify that a variable
is constant each time I am using it as argument for a function that declared that is not
going to modify it ?
Also it doesn't logically seem necessary.
It is like the Standard C++ ( or Microsoft? ) is forcing me to put a const_cast<const ...=""> everywhere.

This was not a problem with vc70.

Similar issue, but not identical, with an example given in vc80 RTM help about the C2666 error.

enum E 
{
    E_A,   E_B
};

class A 
{
    int h(const E e) const {return 0; }
    int h(const int i) { return 1; }
    // Uncomment the following line to resolve.
    // int h(const E e) { return 0; }

    void Test() 
    {
        h(E_A);   // C2666
        h((const int) E_A);
        h((int) E_A);
    }
};

Why the compiler shouldn't be smart enough to understand that
int h(const E e)
is a better match than
int h(const int i)
?

Why in earth
int h(const E e)
solves the problem, while
int h(const E e) const
does not ?

Thank you very much for any answer before I start to *fix* my code !
Marcello

Re: Overloads resolution crazyness ?

Ryan Binns10-Apr-06 18:33

Re: Overloads resolution crazyness ?

10-Apr-06 18:33

For the first situation...

VCF::String::size_type and string::size_type are not the same type, so neither of the function calls match perfectly. However, both could match using implicit casting rules, hence the ambiguity. If you intend to call the first one, make sure the parameter is string::size_type rather than VCF::String::size_type

For the second situation...

Again, neither overload matches perfectly. You're calling a function called h from a non-const this pointer. The compiler can either implicitly convert this to a const pointer and call the first one, or it can implicitly convert E to an int and call the second one. Neither conversion has preference over the other, so there is an ambiguity. The reason uncommenting the other definition of h works is because it is a perfect match to the function call - there is no conversion required.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Marcello10-Apr-06 21:05

Marcello

10-Apr-06 21:05

Thank you very much for the reply.

Please forget about the VCF::String thing. It was a typo on my side.

Here is a code I made for this question ( it compiles

class Cond
{
public:
	typedef std::basic_string<wchar_t> MyString;

	Cond()  { };
	virtual ~Cond(void) { };

	Cond( const Cond& other ) {
		/* simple implementation just for this example */
		*this = other;
	};

	Cond& operator= ( const Cond& other ) {
		return *this;
	};

	// implementation
	bool split( const MyString& s, MyString::size_type* p = NULL );
	bool split( MyString& s, const bool& trim );
};

inline
bool Cond::split( const MyString& s, MyString::size_type* p )
{
	/* simple implementation just for this example */
	return true;
}

inline
bool Cond::split( MyString& s, const bool& trim )
{
	MyString::size_type p;
	//if ( split( const_cast<const MyString&>(s), &p ) ) // this compiles fine
	if ( split( s, &p ) ) // C2666
	{
		s = s.substr( p + 1 );
		return true;
	}
	return false;
}

I get the error message:
1>d:\projs\libraries\vcfex\src\conditions\test.h(51) : error C2666: 'vcfex::Cond::split' : 2 overloads have similar conversions
1> d:\projs\libraries\vcfex\src\conditions\test.h(37): could be 'bool vcfex::Cond::split(vcfex::Cond::MyString &,const bool &)'
1> d:\projs\libraries\vcfex\src\conditions\test.h(36): or 'bool vcfex::Cond::split(const vcfex::Cond::MyString &,stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type *)'
1> with
1> [
1> _CharT=wchar_t,
1> _Traits=stlp_std::char_traits<wchar_t>,
1> _Alloc=stlp_std::allocator<wchar_t>
1> ]
1> while trying to match the argument list '(vcfex::Cond::MyString, stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type *)'
1> with
1> [
1> _CharT=wchar_t,
1> _Traits=stlp_std::char_traits<wchar_t>,
1> _Alloc=stlp_std::allocator<wchar_t>
1> ]
1> note: qualification adjustment (const/volatile) may be causing the ambiguity

It puzzles me that the C++ standard ( or is just vc80 ? ) is asking
me to specify const_cast when intuitively the compiler should
resolve the two overloads 'without effort'.

A comment on this after the next point.

I understand what you say at the second point.
I agree but I am really surprised at the same time.
I always considered a const function just as a way to tell the compler that that function is not going to change the 'this' pointer. So I can certainly use it from a non-const function.
This is true. And what you say seems probably true too.
Now I know that this 'const' specifier may affect the overload resolution too.

So at the end it seems that the standard C++ is treating a difference between
const and non-const at the same level as a difference between types completely
unrelated. This, even when the the const specifier is just there to tell that
what is specified as const will not be changed by the function using that instance
( the 'this' or the MyString instance )

At this point I wonder if this is one limit of the C++ ( IMHO of course ),
or if it really necessary to have it like that.

Cheers,
Marcello

Re: Overloads resolution crazyness ?

Ryan Binns10-Apr-06 22:50

Quick question about IEEE floating points

10-Apr-06 22:50

Marcello wrote:
So at the end it seems that the standard C++ is treating a difference betweenconst and non-const at the same level as a difference between types completelyunrelated. This, even when the the const specifier is just there to tell thatwhat is specified as const will not be changed by the function using that instance

const isn't just there to portray information to the compiler, it actually changes the type. So char* and const char* are as different (to the compiler) as char* and float. The difference between the two examples is that the compiler has rules for implicity converting between the first pair, but not the second.

So const on a function definition doesn't just tell the compiler that the function doesn't modify any of the class members, it also changes the way the compiler handles ambiguity resolution, as you've found out - because the type of the function is different. Incidentally, this is also why you can have two identical function signatures that differ only in their "constness" - they are different types.

As for your first point, neither of the functions is an exact match, but both of them can be satisfied by implicit conversion rules, so the call is ambiguous. In this case, the first parameter is a MyString&, which matches the second function but not the first, and the second parameter is a MyString::size_type* which matches the first function, but not the second. However, MyString& can be implicitly converted to const MyString&, and also MyString::size_type* can be implicitly converted to const bool&, and the compiler really has no way of knowing which you intended. It has no choice but to flag the ambiguity. Casting either parameter explicitly should remove the ambiguity.

As you have hinted, the VS2005 compiler is much more strict than previous compilers, but it is behaving according to the standard.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Jörgen Sigvardsson10-Apr-06 10:39

Jörgen Sigvardsson

10-Apr-06 10:39

When transmitting these types of values across networks, do I have to consider endianess, or is the IEEE standard defined identically for every platform?

Re: Quick question about IEEE floating points

cmk10-Apr-06 15:04

cmk

10-Apr-06 15:04

You need to consider endianess for float/double as well.
I believe the IEEE standard just applies to the break down of bits for mantessa/exponent, bias, ... for a value in raw byte format.

...cmk

Save the whales - collect the whole set

Logo on a dialog app

LCI10-Apr-06 9:59

LCI

10-Apr-06 9:59

I have a dialog application and would like to include a logo bitmap...
Anyone know an easy way to accomplish this?

David Crow10-Apr-06 10:03

David Crow

10-Apr-06 10:03

LCI wrote:
...a logo bitmap...

Are you referring to a splash screen?

"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain

"There is no death, only a change of worlds." - Native American Proverb

LCI10-Apr-06 10:20

LCI

10-Apr-06 10:20

Not sure what a splash screen is.

But say i have a bitmap logo of walt Disney for example. I just want to be able to have that come up towards the top of my dialog application.

In addition to this, i would also like to know how to change the MFC logo at the top left to one of my choice .

Laxman Auti10-Apr-06 17:55

Laxman Auti

10-Apr-06 17:55

You can create your icon and load that icon instead of the default MFC application icon.

Knock out "T" from CAN'T
You 'CAN' if you think you 'CAN'
Cool | :cool:

David Crow11-Apr-06 2:40

David Crow

11-Apr-06 2:40

LCI wrote:
I just want to be able to have that come up towards the top of my dialog application.

As part of the dialog, like a background?

LCI wrote:
In addition to this, i would also like to know how to change the MFC logo at the top left to one of my choice .

The easiest way to solve this is to replace the .ico file in the res folder. Then rebuild your project.

"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain

"There is no death, only a change of worlds." - Native American Proverb

Logo on a dialog app

_AnsHUMAN_ 10-Apr-06 18:15

_AnsHUMAN_

10-Apr-06 18:15

HICON m_hIcon = (HICON)::LoadImage(AfxGetResourceHandle(),
MAKEINTRESOURCE(IDR_XYZ), IMAGE_ICON,
16, 16, 0);
SetIcon (m_hIcon,false);
ModifyStyleEx(0, WS_EX_APPWINDOW);

This is what you can do to set the icon in the bitmap form on the dialog of your application when IDR_XYZ is the id of the icon you wnt to display

Vision is Always important and so is your ATTITUDE.

Wishes.

Anshuman Dandekar

Ryan Binns10-Apr-06 18:37

10-Apr-06 18:37

You can place a static control on your dialog and call SetBitmap() on it (for MFC) or send it the STM_SETIMAGE message (for Win32)

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Krishnatv10-Apr-06 19:22

Krishnatv

10-Apr-06 19:22

yaa Actually that dialo box is created using Resources or Its
Run Time dialog box

krishna