|
I am working with Dialogbased application.I was created one Modalless Dialogbox part of the application.Now How to send the Message from Modalless Dialogbox window to MainDialog whenever modellessDialogbox closed?Pl Tell me How to implement the SendMessage function?
dadsadasd
|
|
|
|
|
Why not hold a pointer to the main dialog in the modeless dialog and then in OnClose, call a function you provide in the main dialog ?
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Better to store the handle to main dialog window. The SendMessage to that window handle.
greatest thing is to do wot others think you cant
suhredayan@omniquad.com>
messenger :suhredayan@hotmail.com
|
|
|
|
|
Right before the modeless dialog is destroyed, call GetParent()->SendMessage(...). You'll then need a corresponding message handler in the parent (modal) dialog.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I was implemented Like.
1.In the Parent DialogBox I declared like
#define GOODBYE WM_USER+1
ON_COMMAND(GOODBYE,OnGoodBye)
LRESULT OnGoodBye(WPARAM wparam,LPARAM)
{
//implementation
}
2.In the CHildDIalog WM_CLOSE
void OnCLose()
{
GetParent()->SendMessage(GOODBYE,0,0);
DestroyWindow();
}
I was implemented Like that. But I am getting the Result?
How ?
dadsadasd
|
|
|
|
|
asv wrote:
I was implemented Like that. But I am getting the Result?
Ok, so what seems to be the problem?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hi,
I'm writing about 20kb of data into a binary file, but at some point during the file output (usually after a certain amount of objects are required to be saved to disk), some form of corruption occurs. Can anyone help with this? Here is some example code:
<br />
ofstream myFile(lpszPathName, ios::binary || ios::trunc);<br />
<br />
<br />
myFile.write((char*)(&version), sizeof(int));
myFile.write((char*)(&w0.numMeshes), sizeof(int));
myFile.write((char*)(&w0.numLights), sizeof(int));<br />
myFile.write((char*)(&p.pos.x), sizeof(float));<br />
myFile.write((char*)(&p.pos.y), sizeof(float));<br />
myFile.write((char*)(&p.pos.z), sizeof(float));<br />
<br />
for(int m = 0; m < w0.numMeshes; m++) <br />
{<br />
myFile.write((char*)(&w0.world_meshes[m]->numFaces), sizeof(int));<br />
myFile.write((char*)(&w0.world_meshes[m]->numVerts), sizeof(int));<br />
myFile.write((char*)(&w0.world_meshes[m]->numNormals), sizeof(int));<br />
etc... etc... going through all mesh faces, vertices and what not, and then finally a myFile.close().
Exactly the same happens for reading, but using file.read() instead. The read function is exactly the same as it's copied & pasted with just swapping of myFile.write to file.read, although there are a few initializations in between the reading lines which are not there during the writing lines.
It seems to be completely random, and I know this isn't possible in programming! It mostly happens when 12 objects need to be required to save to disk, although sometimes it works fine up to an infinite amount, other times, 5 or 6 objects can be written and the corruption starts.
I'm thinking along the lines of some kind of buffer error happening once it reaches a certain size? If anyone can help me on this problem I would be so greatful.
Yours desperately,
Nathan
|
|
|
|
|
From your code example, I understand that the version and other variables are of type integer, float or similar. Also, according to the writing function, the input is supposed to be a pointer to a character string.
As far as I know, a direct conversion like this is not going to work. What gets written into the file is a character representation of the number. This means, that the integer is readed, converted to it's equivalent character code, and written into the file. Now, as a character can only have 8 bits, this works until a certain number limit is reached. When this happens, an over/underrun in the bit sequence happens (INT_MAX becomes INT_MIN, for example) and the character value written into the file no longer represents the actual data.
What you should do, instead, is use an intermediate buffer, into which you convert the value (int-to-string / long-to-string). There is no float-to-string conversion, as far as I know.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thank you for your further explanation! I must have understood the concept wrong, as I imagined that sizeof(type); would have specified exactly the size in bits to be written in, and that the (char*) cast at the start was only required to write to the file.
|
|
|
|
|
I think that the conversion to char* is OK. Because integer is converted to an array of chars (with appropriate length), no information is scratched.
But for storing and loading basic data types you could use operators >> and << instead of write() and read(). It's more readable 
I know, that these paragraphs probably don't solve all of your problem. So write us, what does your corruption mean? It causes an error message or the read data are different from the written data?
Robert-Antonio
"A piece of paper is an ink-lined plane.
An inclined plane is slope up.
A slow pup is a lazy dog.
Q.E.D.: A piece of paper is a lazy dog."
|
|
|
|
|
Robert A. T. Káldy wrote:
I think that the conversion to char* is OK. Because integer is converted to an array of chars (with appropriate length), no information is scratched.
Unfortunately I fail to see the reason of why this would be correct ? I'm not saying it is wrong, but I just don't know how it could work ?
The way I see it is that the pointer received by the write function specifies the starting point, and the size parameter tells how many bytes are supposed to be copied. Afterall, a char basic type is of size 1 byte on the Microsoft C++ environment.
So, the function starts from the beginning address to copy data into the file on a byte-by-byte basis. It reads one byte of data, and writes it down. An integer is already 4 bytes long, so this won't pose a problem if the integer is in limit of 1 byte dimension. But any number greater than 128 or smaller than -127 (unsigned char) is considered out-of-bounds, and the context of the integer is undoubtly broken, thus corrupting the data. This would require testing, I know, but at this point, it seems more than a useless debate
However, the dumping operators << and >> might provide a better solution, like you have stated. I forgotted them first, thinking that they were only available when using serialization. But, yes, they should work very well, too. I believe they even check the type of source data so no corruption should occur.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Antti Keskinen wrote:
So, the function starts from the beginning address to copy data into the file on a byte-by-byte basis. It reads one byte of data, and writes it down. An integer is already 4 bytes long, so this won't pose a problem if the integer is in limit of 1 byte dimension
Are you saying that if an int has a vlaue of 128 to -127 it only occupies 1 byte?
An integer is always 4 bytes long regardless of its content. (in this C++/compiler implementation)
Roger Allen - Sonork 100.10016
Strong Sad:
Clever I am? Next to no one.
Undiscovered and soggy.
Look up. Look down. They're around.
Probably laughing. Still, bright, watery.
Listed among the top. Ten.
Nine. Late night. Early morn.
Early mourn. Now I sleep.
|
|
|
|
|
Basically, yes, though I might have presented it in an obscure manner.
An integer that is under the first 255 numbers from zero (0-255 or +128/-127) uses the last byte to designate it's value. All other bytes are zero. So, on writing this integer into a file, there will be three zero-bytes and one "data" byte.
Hence the saying "the integer is in limit of 1-byte dimension", meaning, that one byte is enough to represent the actual integer, though 4 bytes are always used, like you said.
Considering that an integer is "always" 4 bytes long in the memory (or in a file), it's representation in the file, whether it was one or more bytes long, should always show up correctly in memory as well, as memory-wise copying is done on byte-by-byte basis by the reading/writing functions. Or, this is how I have understood that they work..
This means that if the data becomes corrupted while doing this, there might be a compiler optimization command responsible that links the adjacent bytes to each other. Like, could it be that the 'size' optimization command decreases the memory requirement of an integer if it doesn't require all four bytes to represent itself ?
If the integer only requires two bytes to represent itself, the compiler, when executing with an optimization, actually caps the integer's length into two bytes ? I know this doesn't sound logical at all, but well, I'm quite outta ideas on why the data might get corrupted, as it does
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
The function ostream::write(E* buf, streamsize n) writes n elements of (templated) type E, starting at position pointed by buf. In our case it will write four chars, that covers the 4-byte memory block, in which the integer is stored. What is wrong?
I don't know about any optimization, which compresses intergers to smaller sizes. 4 bytes is the default length of integer on all 32bit platforms.
Robert-Antonio
"I launched Norton Commander and saw, drive C: on the left, drive C: on the
right...Damn, why I need two drives C:??? So I formatted one..."
|
|
|
|
|
Nothing should be wrong, but according to the original poster, the data gets corrupted in random positions during the writing. This means that something is wrong with the routine, and I was just curious to find out what this reason is..
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hello all,
I have some questions about inline function, if I have something like this
<br />
class myClass<br />
{<br />
protected:<br />
int i;<br />
<br />
public:<br />
inline Set_I(int val)<br />
{i = val;};<br />
}<br />
<br />
int main()<br />
{<br />
myClass c;<br />
c.Set_I(10);<br />
}<br />
I want to know what will actually happen. Since Set_I() is an inline function, the compiler will replcae the definition of the function in where the function has been invoked. However, in this case the inline is actually accessing the protected member of the class, so what will happen??
Thanks!
Nachi
|
|
|
|
|
nachilau wrote:
However, in this case the inline is actually accessing the protected member of the class, so what will happen??
Exactly the same thing. The protected keyword tells the compiler that the i variable can be accessed by members of myClass or its derivatives. This condition is still true. Whether or not the compiler inlines the member functions makes no difference at all. It is still the same function accessing the same variable.
Hope this helps,
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"
|
|
|
|
|
|
nachilau wrote:
compiler will replcae the definition of the function in where the function has been invoked.
No. inline is a suggestion to the compiler, it can choose to ignore it.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
inline is an important keyword, but it must be used as:
1. in h file, but not inside class scope(if so, it is ignored)
2. not in cpp file (if so, it is ignored)
example is
//MyClass.h
class MyClass
{
public int Get();
};
inline
int MyClass::Get(){return 1;}
advantage of inline function is
1.(at least books say) it is faster than normal function.
2.in case of you need to put your code on head file (e.g. craete library)
includeh10
|
|
|
|
|
includeh10 wrote:
public int Get();
};
inline
int MyClass::Get(){return 1;}
2.in case of you need to put your code on head file (e.g. craete library)
In fact, the compiler is trying to inline any function defined in the *.h-file. Regardless of inline or not.
If you want to suggest to inline a function with a body in the *.cpp-file, you add inline before the declaration in the header file.
In any case, you are only giving a suggestion, you can not force the compiler to do the inlining.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
i think u never use inline before.
code above can not be compiled if no keyword inline.
includeh10
|
|
|
|
|
I am just trying to test this API function on Outlooks
SysListView32 control.
ListView_GetItemCount works fine but ListView_GetItemText
crashes Outlook.
void testListView(HWND listView)
{
int count = ListView_GetItemCount(listView);
printf("%d", count);
printf("\r\n");
char text[25];
//LVITEM item;
//memset(&item, 0, sizeof(item));
//item.mask=LVIF_TEXT;
//item.iSubItem=0;
//item.pszText=text;
//item.cchTextMax=25;
//item.iItem=1;
//SendMessage(listView, LVM_GETITEMTEXT, 1, (LPARAM)&item);
ListView_GetItemText(listView, 1, 0, text, 25);
printf(text);
printf("\r\n");
}
jp
|
|
|
|
|
Are you calling this from another application, or from an Outlook addin? It won't work from another application because Outlook will try to write to an area of memory that does not belong to it, causing an access violation.
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"
|
|
|
|
|
Yes, from another application.
Is there any way to do it?
I don't want to go the AddIn route.
thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
