C / C++ / MFC

4-Apr-08 4:34

So I have this COM object that's packing up an array floats for me.

Here's the loop where the VARIANT* array is getting stuffed:

for (i = 0; i < cElements; i++)
{
     VariantInit(&vDataValues[i]);
     V_VT(&vDataValues[i]) = VT_R4;

     //Works ok UNLESS float_data[i] == 0.0;
     V_R4(&vDataValues[i]) = float_data[i];

     if (!V_R4(&vDataValues[i]))
     {
          *pErrorCode = 1;
          m_strMessage.Format("V_R4 failed!");
          hr = E_FAIL;
          goto Error;
     }
}

The VT_R4() operation works unless the element in float_data
happens to be 0.0. When that happens, VT_R4 fails.

I know it fails only with 0.0, because I tried this:
if( float_data[i] != 0.0 )
     V_R4(&vDataValues[i]) = float_data[i];
else
     V_R4(&vDataValues[i]) = float_data[i] + 0.1;

Then, it never fails.

I can't figure out why.

led mike4-Apr-08 5:04

led mike

4-Apr-08 5:04

Well I have no idea what your float_data is or if it has been properly initialized but this works without error

    VARIANT DataValues[4];
    V_R4( &DataValues[0]) = 0.0;

led mike

Eurosid4-Apr-08 5:21

4-Apr-08 5:21

I'm new to using COM, so maybe I'm missing something obvious here.

The data I can verify is OK.

led mike wrote:
VARIANT DataValues[4];
V_R4( &DataValues[0]) = 0.0;

Those lines work for me, too.

The examples I'm looking show that you verify it's OK by doing this sort of thing:

if (!V_R4(&vDataValues[i]))
{
//Do some error stuff
}

And !V_R4(&vDataValues[i]) evaluates to false if the data is 0.0.

Why is that? Confused | :confused:

If I comment out that error check, everything seems to work fine. Is it not needed?

led mike4-Apr-08 5:32

led mike

4-Apr-08 5:32

Eurosid wrote:
The examples I'm looking show that you verify it's OK by doing this sort of thing:

I don't think that's correct. Where are you getting these examples?

V_R4 is just a macro that evaluates to the specified VARIANT member during pre-compile. It does not return an status indication value.

led mike

Eurosid4-Apr-08 5:49

4-Apr-08 5:49

You are exactly correct. I misunderstood what I was looking at.

The example was for packing up a BSTR, so they did such a check
to make sure the pointer wasn't NULL.

Doing the same thing on a float isn't needed, but will look OK unless the value happens to be 0, which will look like FALSE.

I told you I was a Chump!

Thank you for help!

Iain Clarke, Warrior Programmer

Iain Clarke, Warrior Programmer4-Apr-08 5:43

4-Apr-08 5:43

I'm slightly curious what you mean by "fails". Do you put the variant in a watch window, and see wrong numbers? From your later post, I think you think that V_R4 is a function which passes success / failure.

Looking in OLEAUTO.H,

#define V_UNION(X, Y)   ((X)->Y)
#define V_VT(X)         ((X)->vt)
#define V_R4(X)          V_UNION(X, fltVal)

So...

VARIANT var;
VariantInit (&var);
V_VT(&var) = VT_R4;
V_R4(&var) = 0.0;

becomes

V_UNION(&var,ftlVal) = 0.0;

becomes

(&var)->ftlVal = 0.0;

which looks fine to me.

BUT:

You are using this in an if statement.

Imagine the following:

if (1)
{
   //  pretty guaranteed to get here
} else {
   // not likely...
}

and

if (a=0)
{
   //  pretty unlikely to get here
} else {
   // 
}

The second if evaluates to 0, which will fail the if.

Cutting to the chase:

V_R4(&blah) = a number

evaluates to whatever the number is - and 0 is FALSE.

Here endeth the lesson.

Iain.

Iain Clarke appears because ^CPallini still cares.

Eurosid4-Apr-08 5:51

4-Apr-08 5:51

Iain Clarke wrote:
Here endeth the lesson.

Iain.

Yes. That was it. I was being a Chump.

I knew it, but I just couldn't see why. Blush | :O

Thanks!

primary key

Try4-Apr-08 4:34

Try

4-Apr-08 4:34

How to determine which field in a database table is the
primary key (in OLEDB or ODBC) using MFC (VC++ 2005)?

Thanks in advance..

Nitheesh George4-Apr-08 4:45

Nitheesh George

4-Apr-08 4:45

Hi,

I don't think this can be done using MFC. You can find it from sys tables of the database.

thanks

Nitheesh

David Crow4-Apr-08 6:08

David Crow

4-Apr-08 6:08

I do not think anything has changed since you last asked this question. Just out of curiosity, why do you need to know such information (i.e, what part of your code is relying upon it)?

"Love people and use things, not love things and use people." - Unknown

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Try6-Apr-08 1:29

Try

6-Apr-08 1:29

I will update a field (Say fieldName)in the application. A trigger is executed outside the application in oracle, which changes the value of another field (Say fieldNumber=1, Now changed to fieldNumber=2 after trigger).

The method i follow after field update is :
1. Update (fieldName) to database
2. Refresh the updated value and trigger changed value (fieldNumber=2) to text box. I am doing refresh using select statement .. where ...

(select * from tbl where fieldNumber=1)

Since the trigger changes value outside application, my select statement's where clause have old value (fieldNumber=1). It fails.

Hence i want to know the primary key of the table and use refresh using select statement (only primary key)..

A strange problem with CRecordset derived class

Mark Salsbery4-Apr-08 7:26

Mark Salsbery

4-Apr-08 7:26

With ODBC, there's SQLPrimaryKeys()[^]

Mark

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

Joseph Marzbani4-Apr-08 3:27

Re: A strange problem with CRecordset derived class

4-Apr-08 3:27

I have a class derived from CRecordset. Please note:

Code "A":

<br />
CString CMyClass::GetDefaultConnect()<br />
{<br />
      return L"Connection String";<br />
}<br />

Code "B":

<br />
CStringW strConnectionString=L"Connection String";<br />
<br />
CString CMyClass::GetDefaultConnect()<br />
{<br />
      return strConnectionString;<br />
}<br />

My problem is that code "A" works fine, but when I use code "B", I encounter the following error code when closing my app:

"The instruction at "0x00efefa" referenced memory at "0x00ef004". The memory could not be "read". Click on OK to terminate the program."

Please help me...

prasad_som4-Apr-08 3:37

prasad_som

4-Apr-08 3:37

Out of curiosity, Why not used _T macro, instead of L literals. And CString instead of CStringW.

Code "A":

CString CMyClass::GetDefaultConnect()
{
return CString(_T("Connection String"));
}

Code "B":

CString strConnectionString= CString((_T("Connection String")));
CString CMyClass::GetDefaultConnect()
{
 return strConnectionString;
}

This could not be related to actual porblem, but this is my suggestion.

Re: A strange problem with CRecordset derived class

Cedric Moonen4-Apr-08 3:41

Cedric Moonen

4-Apr-08 3:41

See here[^]

Furthermore, you shouldn't use CStringW directly, your code won't compile if you remove UNICODE.

Cédric Moonen
Software developer

Charting control [v1.3]

Re: A strange problem with CRecordset derived class

Joseph Marzbani4-Apr-08 3:56

Re: A strange problem with CRecordset derived class

4-Apr-08 3:56

Thanks for your reply!
I did your advice, but the problem is permanent yet...

I don't know what I can do...

Cedric Moonen4-Apr-08 3:59

Cedric Moonen

4-Apr-08 3:59

Usef Marzbani wrote:
I did your advice

So, what information did you gather from the debugger ? You have to understand that nobody can help if you don't provide valuable information, and one way to get this info is by using your debugger.

Cédric Moonen
Software developer

Charting control [v1.3]

Re: A strange problem with CRecordset derived class

CPallini4-Apr-08 4:00

CPallini

4-Apr-08 4:00

Usef Marzbani wrote:
I don't know what I can do...

for instance

CString strConnectionString = _T("Connection String");

CString CMyClass::GetDefaultConnect()
{
return strConnectionString;
}

and make sure strConnectionString cannot go out of scope.
Smile | :)

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

Re: A strange problem with CRecordset derived class

CPallini4-Apr-08 3:51

CPallini

4-Apr-08 3:51

Actually I see strange code... D'Oh! | :doh:

Re: A strange problem with CRecordset derived class

Joseph Marzbani4-Apr-08 3:58

Re: A strange problem with CRecordset derived class

4-Apr-08 3:58

You could give me a better solution...

David Crow4-Apr-08 6:20

David Crow

4-Apr-08 6:20

Usef Marzbani wrote:
CStringW strConnectionString=L"Connection String";

What happens if you use:

CString strConnectionString = L"Connection String";

"Love people and use things, not love things and use people." - Unknown

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Re: A strange problem with CRecordset derived class

Joseph Marzbani4-Apr-08 8:51