|
modify first line as 2 lines:
const double LogMath::FloatMin = 0;
double db=numeric_limits::min( );
to see which line is error.
|
|
|
|
|
i modified the code as below:
<br />
const double LogMath::FloatMin = 1.17549e-038;<br />
const double db = numeric_limits<float>::min( );<br />
const double LogMath::FloatMax = 3.40282e+038; <br />
const double dc = numeric_limits<float>::min( );<br />
but ended up with the same errors
any other tips ?
Thanks for replyin
|
|
|
|
|
Hi,
I have created a new child window with the following method
AfxGetMainWnd()->SendMessage(WM_COMMAND, ID_FILE_NEW);
but when I display data on this window, the display starts on the left border of the window and then I need to give CRect.left +10 for the x-coordinate so that the data is properly displayed after the border line and
I can see the border line.
Can I avoid this +10 somehow so that I can directly use
GetClientRect(Rect) and print on Rect.left ?
Thanks
|
|
|
|
|
Take a look at SetWindowOrg() and SetViewportOrg().
Here[^] is an excellent article that you can use to alleviate any confusion you may have about those functions.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Hello, I am try to read an MS-ACCESS 2000 .mdb file with DAOVIEW example included in MSDN. I get error 3343 and I know it is due to DAO 3.51 (I know I need DAO 3.60) but.... what must I do to shift to DAO 3.60 in VC6.0 ?
Regards
giannib2k
|
|
|
|
|
giannib2k wrote: I get error 3343...
This is all but completely meaningless without showing the code snippet that produced the error.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Does this[^] help at all?
(go to MSDN home page and enter DAO 3.6 MFC in the search box...)
Steve S
Developer for hire
|
|
|
|
|
Yes, it helps a lot
Problem solved
thanks
|
|
|
|
|
Hey,
please help me. I've got a SDI-App with a non modal dialog. The dialogs only task is to choose parameter (e.g. in a listbox) for my application.
After selecting an item in the listbox (on dialog) the focus should move to my a control (choosen by listbox) in my cformview(e.g. CEdit - Control).
I handle the OnLvnItemChangedList message in my dialog. In this function I post a message (WM_SETFOCUS) to my (formview) window. But the focus returns immediately back to my dialog.
When I set the focus to my mainwnd (by mouseclick) the focus is in the right control. But how can I set the focus to my mainfrm automatically?
Thanx for your help
|
|
|
|
|
if u set focus to parent formview, the parent will set focus to its child which has focus before the parent gets focus automatically - so ur dialog gets focus back.
in ur function - OnLvnItemChangedList - u should tell formview where to send focus.
i.e. post a message to formview with wParam==control's ID, so in formview, u send focus to the control.
|
|
|
|
|
I tried your suggestion, but with partial success. When my dialog has the focus before I select an item on the listbox it works fine, but if the focus is on my formview or mainfrm and I select on item, the focus wents to my formview for a second and then switched back to my dialog...
|
|
|
|
|
|
I have an app that I need to shut down after a certain amount of time (eval version). I use a PostQuitMessage, which handles cleanup and works fine in most cases, but if I have a dialog opened through a DLL call (one of my own), it closes the DLL dialog, but not the main app.
What would be the proper (or clean) way to shutdown the DLL dialog(s), then the main app (dialog based)?
TIA
|
|
|
|
|
I have had this issue myself and would too like to know if there is some Zen approach that gives a warm fuzzy feeling.
Simply, the way I saw it was, that there is a higherachy of modal windows that have to be killed off in the right sequence.
It's interesting that the PostQuitMessage message you sent to the app seemed to be passed along to the right window rather than causing you trouble. It might just be best in that case to do the following:
while(::IsWindow(appWindow)) {
::PostQuitMessage(1);
}
If that doesn't work, do what I did, which was to start at the further most relevant child window and post to them each a WM_CLOSE message.
This may not be what you wanted to hear and I'll be watching this thread closely to see if anyone has any better ideas but in lieu of any other responses I thought you may at least like to know that there is commercial software out there that uses this technique
Tom
|
|
|
|
|
I tried doing this, which does seem to work...
I set a bool whenever I call my DLL.
<br />
if( m_bLibOpen )<br />
{<br />
PostQuitMessage(SC_CLOSE);<br />
}<br />
<br />
AfxGetMainWnd()->PostMessage(WM_CLOSE, 0, 0);<br />
This does seem to close multiple dialogs opened by my DLL, along with my main app, but somehow, it still doesn't seem "clean" to me.
I'm playing around with EnumChildWindows now...
|
|
|
|
|
|
It should work: I don't know Linux but this is standard C++.
If you explain what the problem is, maybe we can help.
|
|
|
|
|
As Cedric already noted, this should work.
What error do you get?
|
|
|
|
|
Make sure you are spelling the file name EXACTLY right. Windows is not case sensitive, but Linux is.
http://en.wikipedia.org/wiki/Comparison_of_file_systems[^]
--EricDV Sig---------
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.
- Laurence J. Peters
|
|
|
|
|
|
Paul Tawk wrote: #include iostream.h
#include fstream.h
Those are old-style headers. The standard has changed them to be the following (on all platforms):
#include <iostream>
#include <fstream>
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Nemanja Trifunovic wrote: What error do you get?
--EricDV Sig---------
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.
- Laurence J. Peters
|
|
|
|
|
I don't know the compiler you are using, but it might be that you must "turn on" the support for STL.
In the Acc compiler (on a HP-UX machine), it's done by adding -AA to the command line, both at compile and linking.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
I have two selfwritten libraries, one of wich uses the other. If just add the first one to the dependecies of the second one without actually using it or including any of the header-files or anything, i get a
LNK4006: symbol already defined in object; second definition ignored
for every single symbol in the first library. Can anyone tell me why that is and what i can do about it ? I'm allways eager to eliminate all warnings.
|
|
|
|
|
if you make one library dependent on another, VS will merge the the two together so that the second library is contained within the first library.
the fix is: you only need to link to the 'parent' library, since it will have a copy of the second library in it already.
|
|
|
|