C / C++ / MFC

How to add Messsage After installling Application using MSI

5-Mar-10 6:31

real numbers stored in binary are an approximation of strings represented in decimal, or vice versa; your system cannot easily represent 2/3 nor 1/10 accurately. The best you can do is:
- convert strings to reals, and live with the outcome;
- perform real operations on them;
- output to decimal strings with a specified precision.

And of course, if logic dictates (e.g. rounding rules in finance) use a rounding function.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.

am 20095-Mar-10 3:53

am 2009

5-Mar-10 3:53

Hi ,

I had developed one MSI for my application. In this MSI, I add custom action by calling EXE to display message. When I run this MSI , my custom message is pop up before the Close button of last screen.But I want to show message after user click on Close button of last screen.
If any body know regarding this, please reply to me.

Re: How to add Messsage After installling Application using MSI

Richard Andrew x645-Mar-10 15:31

Richard Andrew x64

5-Mar-10 15:31

You must put the EXE as a custom action appearing after the "setup complete" dialog.

How did you develop the MSI, what application did you use?

Structure/Class member addresses

Mike the Red5-Mar-10 2:58

Mike the Red

5-Mar-10 2:58

struct myStruct {
	int x;
	int y;
	char ch[10];
};
struct myOtherStruct {
	int y;
	char ch[10];
	int x;
};
class myClass {
public:
	myClass() { };
	~myClass() { };

	void someMethod(int x) { /*do something with x*/; };
private:
	int a;
	int b;
	char ch[10];
};

int main() {

	myStruct	s1;
	myOtherStruct	s2;
	myClass		c;
	return 0;

};

Given these struct/class definitions, is it always safe to assume:

<br />
&s1.x < &s1.y < &s1.ch<br />
&s2.y < &s2.ch < &s2.x<br />
&c.a < &c.b < &c.ch<br />

(Considering the addresses as numbers, like you'd get from (__int64)&s1.x)

Maybe an easier way to ask this is, "Is the order of the members in memory the same as the order in which they are declared?"

Thanks in advance for any help you guys can offer!

CPallini5-Mar-10 3:22

5-Mar-10 3:22

Yes, AFAIK.
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

[My articles]

Thanks, Pallini! -nt-

Mike the Red5-Mar-10 3:43

Mike the Red

5-Mar-10 3:43

-nt-

Luc Pattyn5-Mar-10 4:12

5-Mar-10 4:12

Mike the Red wrote:
Is the order of the members in memory the same as the order in which they are declared?

No, absolutely not. Without additional information, any compiler can do as it pleases, as long as it is consistent. Here are two typical approaches:

1. reorder the items according to element size, possibly reducing struct size: since items want to be "naturally aligned" (i.e. a N-byte quantity starts at an address that is a multiple of N for best performance) it may pay off to put the largest ones first.

2. keep the declaration order and pad with dummy bytes to achieve natural alignment.

Not a single strategy is good for all purposes as one may want compatibility with another language, an existing data structure in a file, a set of registers in a hardware device, etc.

Hence, most compilers have switches and/or pragma's to control the exact behavior. You should read the documentation of your tools.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.

Saurabh.Garg5-Mar-10 4:19

Saurabh.Garg

5-Mar-10 4:19

C++ standard says that ordering of variables with in a single access block must be in the order they appear but different blocks can be arranged in arbitrary order. For example:

class Foo
{
public:
    int x;
    int y;

private:
    int _x;
    int _y;
};

address of x < address of y
address of _x < address of _y

But you cannot determine relation between address of x and _x. Compiler is free to place then in any order.

-Saurabh

Luc Pattyn5-Mar-10 4:25

5-Mar-10 4:25

I don't think so. Can you provide a link to the section that says so?

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.

Saurabh.Garg5-Mar-10 4:37

Saurabh.Garg

5-Mar-10 4:37

Okay I admit I made the comment based on excellent book "Inside the C++ Object Model".

But I check the C++ standard and it is there in Section 9.2 point 12:
"Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members separated by an access-specifier is unspecified (11.1). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions (10.3) and virtual base classes (10.1)."

and Section 11.1 point 3:
"The order of allocation of data members with separate access-specifier labels is unspecified (9.2)."

-Saurabh

Luc Pattyn5-Mar-10 4:50

5-Mar-10 4:50

Thanks.
So it says it is not always safe to assume the order is preserved.
That is what I remembered, however I didn't know the exceptions were documented as well.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.

CPallini5-Mar-10 5:26

5-Mar-10 5:26

In the example the OP submitted it is always safe. Smile | :)

Luc Pattyn5-Mar-10 5:32

5-Mar-10 5:32

"always" and "example" indicate an interest in the general answer, covering a broad domain.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.

CPallini5-Mar-10 5:59

5-Mar-10 5:59

Please don't cheat, his question is actually very well defined. Big Grin | :-D

Luc Pattyn5-Mar-10 6:05

5-Mar-10 6:05

do you really believe the code shown is the actual code?
that was only the tip of some iceberg; we can only guess what stuff is hiding below the surface.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.

CPallini5-Mar-10 6:24

5-Mar-10 6:24

Of course I don't believe that's the actual code and I'm pretty sure it hides tons of code behind. Anyway my point is still valid (and you know that Poke tongue | ;-P

).

BTW it is friday, have a Beer | [beer]

or two.

Avi Berger5-Mar-10 5:11

Avi Berger

5-Mar-10 5:11

I thought I recalled what Luc Pattyn said, but went searching and basically came up with the same thing that Saurabh has presented. There is also a difference between the current C++ standard and the draft of the next standard. The current guarantees order only until the next access-specifier specifier.

The text in the draft for the new standard is:
Nonstatic data members of a (non-union) class with the same access control (clause 11) are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with different access control is unspecified (11).

So to extend Saurabh's example:

class Foo<br />
{<br />
public:<br />
    int x1;<br />
    int y1;<br />
<br />
private:<br />
    int x2;<br />
    int y2;<br />
<br />
public:<br />
    int x3;<br />
    int y3;<br />
};

The draft for the new standard (unless its been changed from the one I looked at Smile | :)

) guarantees the order x1 - y1 - x3 - y3, while under the current standard the storage order of x1 and x3 is unspecified.

Please do not read this signature.

Data Type Conversions

Andy2025-Mar-10 2:06

Andy202

5-Mar-10 2:06

I have been trying to interface with a software program which uses a message made up of a 20 word array of unsigned shorts;

unsigned short messageData[20];

I have been trying to use data from a home GPS system which includes Lat and Long and heading.; these have been converted from strings to floats.

e.g.

float lat, long, heading;

My problem is that as I know the scaling factors and least Sig Bit (LSB) for the lat, long and heading in the messageData buffer;

e.g.
For lat and long
LSB = 8.377E-08; Twos complement - 32 bits Max/ Min -180 to +180

For Heading
LSB 0.00549306; Twos complement - 16 bits Max/ Min -180 to +180

Setting the heading:-
unsigned short heading = (unsigned short)(newHeading/0.00549306);
messageData[10] = heading;

Getting the heading:-

bool negative;
unsigned short currentField = messageData[10];
if(currentField & 0x8000) 
{
	// Set the negative flag
	negative = true;
}
else
	negative = false;
float heading = (currentField & 0x7FFF) * g_nScalings[wordPos];
if(negative)
	heading = -(180 - heading);

But this does not work as I expected; am I missing something?

As for the 32 bit latitude, I was going to this:-

Setting the Latitude:-

union
{
	int lat_long;
	unsigned short buff[2];
}convert;

unsigned short highWord, lowWord;
int newData = (int)(fEngValue/8.377E-08);

convert.lat_long = newData;
highWord = convert.buff[1];
lowWord = convert.buff[0];

I need to get and set data in the message that is of type unsigned short and use in my program as scaled floats.

Any suggestions please.

CPallini5-Mar-10 3:28

I'm not following the math you're doing, but maybe this will help..

5-Mar-10 3:28

Could you please elaborate a bit. Confused | :confused:

Could you post inputs, wrong and expected outputs?
Smile | :)

Mike the Red5-Mar-10 3:33

Mike the Red

5-Mar-10 3:33

If you're dealing with floats that have been converted to strings, just convert them back to floats.

The unsigned short is the same as wchar_t - you should be able to use an explicit cast to 'convert' between them.

_wtof() converts a wchar_t string to a double, which you can then cast to a float, if the value is withing the range of type float.

_ecvt() converts a double (or float cast to double) to a wchar_t string, though you'll have to do some string manipulation to put the sign and/or decimal in the indicated place(s).

Both functions are in <stdlib.h>.

Hope this is useful,

MZR

Re: I'm not following the math you're doing, but maybe this will help..

Andy2025-Mar-10 8:12

Andy202

5-Mar-10 8:12

Sorry not made myself very clear.

Forget about strings to floats thats OK.

I need to cast from a float to a unsigned short using the information about the format about the unsigned short;

e.g. top bit is sign, LSB is the scaling.

Now if I run my code with a heading set to 3.45 this sets the unsigned short to 0xB999 which is not what I expected.

Or looking at it the other way if the value of the unsigned short is 0x0001 then this would represent heading = (float)0x0001 * LSB.

The messageData holds the data as unsigned shorts which need to be processed on Get and Set if that makes sense.

For Lat and Long two elements are used, for heading just one.

Luc Pattyn5-Mar-10 4:19

5-Mar-10 4:19

1. could you give some actual data samples, where both the short representation and the real value are known?
four or more pairs would be good.

2.
for 32-bit data, for sure there only is one sign bit, so both halves need different treatment.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.

Andy2025-Mar-10 10:48

Andy202

5-Mar-10 10:48

Just to recap and get things right in my mind; if a heading value is represented as an unsigned short (16 bits) with bit 1 = 0.000030517578125; so the range is -1 to + 1 and if we multiple by 180 we get -180 to +180 degrees - more useful

Now for a test I set heading to 3.45 then the following occures.

3.45/0.000030517578125 = 1B999 in Hex; but as we can only store 16 bits in the unsigned short the debugger shows B999 as the value.

Now when I come to decode that vaue via:-

B999 * 0.000030517578125 = 1.44998169 which is wrong and if x 180 to get into degrees then get 260.99.

Now for reading another value say, e.g. the value is 1234hex then we get:-

1234Hex * 0.000030517578125 = 0.14221191 and if we convert into degrees then get 0.14221191 * 180 = 25.598144 degrees.

Hope this helps to explan what I am trying to do.

Luc Pattyn5-Mar-10 11:38