|
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.
|
|
|
|
|
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
|
|
|
|
|
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>
</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.
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
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;
static bool getVariableState( string& rs, int& idxVar, const bool& trim );
);
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; }
void Test()
{
h(E_A);
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
|
|
|
|
|
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"
|
|
|
|
|
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 ) {
*this = other;
};
Cond& operator= ( const Cond& other ) {
return *this;
};
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 )
{
return true;
}
inline
bool Cond::split( MyString& s, const bool& trim )
{
MyString::size_type p;
if ( split( s, &p ) )
{
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
|
|
|
|
|
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"
|
|
|
|
|
When transmitting these types of values across networks, do I have to consider endianess, or is the IEEE standard defined identically for every platform?
|
|
|
|
|
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
|
|
|
|
|
I have a dialog application and would like to include a logo bitmap...
Anyone know an easy way to accomplish this?
|
|
|
|
|
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
|
|
|
|
|
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 .
|
|
|
|
|
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'
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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"
|
|
|
|
|
yaa Actually that dialo box is created using Resources or Its
Run Time dialog box
krishna
|
|
|
|
|
|
Hi all,
I have a simple question.
I used
::UpdateWindow(m_hWnd); and ::UpdateWindow(::GetParent(m_hWnd));
in my program so i can see the updated control data on window dlg data. It only works during debug but when the program is not running in debug mode, it freeze and I can no longer see the control updates.
May I please know how to fix that problem so I can see updates on the dialog controls/static.
Thanks
|
|
|
|
|
A common problem in release (vs. debug) builds is the use of uninitialized variables (which contain garbage in release mode and zero in debug mode). Check your code for these. If the problem persists, you'll need to post a code snippet (not your entire app!) in order to get more help.
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
pnpfriend wrote: I used
::UpdateWindow(m_hWnd); and ::UpdateWindow(::GetParent(m_hWnd));
in my program so i can see the updated control data on window dlg data.
What exactly are you updating? UpdateWindow() updates the client area of the specified window (or control) by sending a WM_PAINT message to it. Is that what you are expecting?
"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
|
|
|
|
|
Yes.. I think that I am expecting.
I have static control that keep track of num of files in the loop like 1 2 3 4 5 ..
in debug mode, you can see the num of files: increasing as the loop goes on even you open other windows. If it is not running in debug mode, the increasment still as soon as i touch other windows. It looks like the program is freezed but busy working.
Isn't ::UpdateWindow(m_hWnd) solution to this? What am I doing wrong?
Thanks
|
|
|
|
|
pnpfriend wrote: Isn't ::UpdateWindow(m_hWnd) solution to this?
Not hardly.
pnpfriend wrote: What am I doing wrong?
You need to create two CStatic variables, one for each control. Make sure the DoDataExchange() method is correct:
void CMyDialog::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX, IDC_STATIC1, m_static1);
DDX_Control(pDX, IDC_STATIC2, m_static2);
}Now when you need to update them, simply call SetWindowText() like:
int nCounter = 1;
CString strCounter;
strCounter.Format("%d", nCounter);
m_static1.SetWindowText(strCounter);
"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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
