|
Some numbers just won't convert, it's to do with representing them in binary rather than decimal. That's why they're described as 'floating' point numbers, or double precision f.p. numbers. Doubles aren't any more precise, but they can accomodate a larger working range.
If you can handle a fixed number of decimal places, you might want to use large integers instead (__int64) with a fixed divisor, like 1000, but this obviously depends on what range you're dealing with. The OLE CURRENCY type does something along these lines.
Steve S
|
|
|
|
|
hello, i have writen a winsock aplication using visual c++. i have wrote a new non mfc class to handle a recv thread in my program. the problem is i need to access some of the varibles from my original mfc class,the varible i need to write to is a static text CString.
the varible was declared with the class wizard wich aut:-Domaticaly assighned a varible to the static text id.
is there a way i can access this varible from my new non mfc class,or would i have to declare the CString as global?
if so how would i go about this?
thankyou in advance
chris 
|
|
|
|
|
Are you wanting read access (in which case you could just use an LPCTSTR), or write access? If the latter, then you've just put in a dependency on MFC in your shiny new class...
Steve S
|
|
|
|
|
Steve S wrote:
If the latter, then you've just put in a dependency on MFC in your shiny new class...
Couldn't CString::GetBuffer() be used to "pass" the buffer to the other thread?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
[fx:blush]
Yes, of course it could.
Steve S
|
|
|
|
|
hmmm well its definatley the latter,im trying to update the string with new information obtained from my server,but becouse im stuck in my "shiney new thread class" i cant seem to write from my inBuffer wich is in my thread class to my varible..
this is very annoying coz i cant use functions like UpdateData(); from my new class either.
thank you for your speedy response & any further help would be much appreciated.
thanks again
chris
|
|
|
|
|
Sounds like you have a CString in your dialog class which is being used by DDX_Text. If you want to update the data, you could use SetWindowText instead, which means you'd need the window handle for edit control instead of the CString.
Steve S
|
|
|
|
|
hahah thank you very much,i have sorted my problem now!
cheerz m8;)
chris
|
|
|
|
|
Hi,
One of my beta testers told me about preparing a build with debug statements being logged in a text file. I'm trying to find a fix for a bug with Exchange Server that I cannot reproduce and I guess that being able to see in a file what happened would be tremendously useful.
I do not, however, know anything about that sort of thing... Anyone can help me out?
Thanks!
---------------
Tired of Spam? InboxShield for Microsoft® Outlook® 2K/2K2/2K3
http://www.inboxshield.com
|
|
|
|
|
An alternative that requires almost no work is to use OutputDebugString to write stuff to the debug window. MFC has TRACE() which does the same, but does nothing in Release builds. OutputDebugString will generate output in all cases.
The next step is to go to the sysinternals web site[^], and get hold of DebugView.
You can run this tool on any windows machine and it lets you catch and save to file the debug output, not just for a single app, but on a system wide basis.
I use it to examine some of the trace output from our COM+ server apps.
Steve S
|
|
|
|
|
You can consider placing ASSERT condition or VERIFY condition in your codes if you haven't. There are many articles on this topic in codeproject.
ASSERT is only available in debug mode. VERIFY however is in both cases.
Many bugs can be spotted by having ASSERTS around.
hope this helps
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
I did place ASSERTs everywhere in the code but I wanted something that could be saved as a file. In that case, it was an infinite loop so the ASSERTs would have been useless but they are useful in some other cases...
---------------
Tired of Spam? InboxShield for Microsoft® Outlook® 2K/2K2/2K3
http://www.inboxshield.com
|
|
|
|
|
not much on google for this one...
I'd like to remove the doc/view from our application, no real need for it.
anyway.
if I do something like :
{ ...
CreateNewChild( RUNTIME_CLASS( MyOtherFrame ), IDR_BIGTESTYPE, ::LoadMenu(hInst, MAKEINTRESOURCE(IDR_BIGTESTYPE)), ::LoadAccelerators(hInst, MAKEINTRESOURCE(IDR_BIGTESTYPE) ) );
...}
when opening a new window, and doing this for other frame class, it's working fine; I don't keep the returned value from CreateNewChild since the frame and the data gets deleted
Is there's a way to iterate the framewnd to close them ? other than iterate the child windows and closing them manually. for example if I want to do a close all window, or close document.
Thanks.
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
What I've done before now is that the CMainFrame class maintains a CArray<> of CFrameWnd pointers which are children, and the OnCreate()/OnDestroy() handlers for the child frame post messages to the main frame window to register/unregister themselves...
Steve S
|
|
|
|
|
say that again ? that you kept an array on CFrameWnd or that the CMainFrame(CMDIFrameWnd) already keeps it ?
thanks.
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
In CMainFrame I had an array of CFrameWnd*, which was updated on receipt of a user defined message. The user defined message was posted when my child frames were created or destroyed. Saves iterating through via EnumChildWindows, as it only encounters child frames, not things like toolbars and the like.
Steve S
|
|
|
|
|
thanks, I tried it on a sample project, and it's working nicely,
Will see how I can integrate it into my main application.
Thanks.
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
Hi there 
I have written a program that takes a single frame from a video camera and writes it to a .bmp file the problem that I am having is that the .bmp is upside down. The pixel data for my image is contained in a buffer defined as:-
DWORD* pBuffer;
I have used DWORD as the image is 768 * 576 * 32 bit.
Can anyone help with a method of rearranging the DWORDS in my buffer to correct the image. I need it to display top down, not bottom up.
Thanks
Dave
|
|
|
|
|
Might be simpler than that. At some stage, presumably, you have a header for the bitmap you're writing. You might want to check the sign of the height. ISTR that sometimes some handlers object to -ve height, and invert the image. Of course, I might be talking through my hat, but it won't hurt to check...
Steve S
|
|
|
|
|
I have tried that method, I am specifying the whole bitmap structure but if I make the height negative I get an error saying something like the height needs to be greater than 0 when you try to open the bitmap in an image editor.
Thanks
Dave
|
|
|
|
|
Are you just writing the buffer directly to the file? The BMP format internally stores the image data upside down (I recall that there was actually a reason for this, but I can't remember now).
Anyway, you since you know the number of rows and the size of each row, you can just allocate a temporary buffer the same size as your original buffer, then copy rows of data from the first buffer to the temporary buffer. Something like this:
int rows = 576;
int cols = 768;
DWORD* destbuf = (DWORD*)malloc(rows * cols * sizeof(DWORD));
for (int row = 0; row < rows; row++) {
memcpy(
destbuf + (row * cols),
pBuffer + ((rows - row - 1) * cols),
cols * sizeof(DWORD)
);
}
- Mike
|
|
|
|
|
Cheers Mike I'll give that a go today. Tried to use memcopy yesterday but kept gettin exception errors and bombing out into debug. Im learning so I dont have any expirience with the debugger I havent a clue what it all meant. I'll see how it goes.
Thanks
Dave
|
|
|
|
|
Steve S is right. Get your hands on the BITMAPINFOHEADER structure located in your buffer, then negate the biHeight value. From the MSDN:
biHeight
Specifies the height of the bitmap, in pixels. If biHeight is positive, the bitmap is a bottom-up DIB and its origin is the lower-left corner. If biHeight is negative, the bitmap is a top-down DIB and its origin is the upper-left corner.
If biHeight is negative, indicating a top-down DIB, biCompression must be either BI_RGB or BI_BITFIELDS. Top-down DIBs cannot be compressed.
[edit]For clarification, Michael is also right. His solution will work, it just depends on what you really want to do.[/edit]
Chris Richardson
|
|
|
|
|
Chris Richardson wrote:
Get your hands on the BITMAPINFOHEADER structure located in your buffer, then negate the biHeight value.
I have tried that method, I am specifying the whole BITMAPINFOHEADER structure myself but if I make the height negative I get an error saying something like the height needs to be greater than 0 when you try to open the bitmap in an image editor.
Thanks
Dave
|
|
|
|
|
Hello,
How can I open a browser without address bar ?? Which line argumets ??
[]'s
Cris.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
