|
Under normal conditions, the calculated point should show in the right spot --your calculations should be far more accurate than the screen resolution. Si, maybe the code has some little bug.
As for the roundoff thing, long int li=(long int)(d+0.5) should do.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You will most likely need to translate your coordinates to the view's reference frame. Simply offset the point as far as your point of reference for the calculation is from the origin of the view's coordinates in both X and Y. (0,0) is the upper left corner of the view if I can recall...
For round-off, you can simply cast it as follows:
double dblData = 1.8787281;
long int liData = static_cast<long int>(dblData);
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Nitron wrote:
For round-off, you can simply cast it as follows:
double dblData = 1.8787281;long int liData = static_cast<long int="">(dblData);
scrap that, i'm an idiot! That will truncate the double!
Sorry!
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
I am developing a MFC SDI Application connecting to a SQL Server database through ADO.
The problem in hand is that if multiple users are connected to the database and if one user makes any change in database, a message describing the change need to be propogated to all other connected users. It will depend upon user if he want to load this change or not.
Any ideas on how to do this? If you guys could provide me some sample code that would be great
|
|
|
|
|
I'm having difficulty resizing a Metafile. I tried using StretchBlt without any luck. Any ideas,
Thanks
|
|
|
|
|
Metafiles are lists of GDI primitives. They should 'draw to fit' without any difficulty. StretchBlt is used to stretch/draw one bitmap onto another, and doesn't work with metafiles. Could you post your drawing code for the metafile?
Software Zen: delete this;
|
|
|
|
|
This article of mine has example code for displaying a metafile form the clipboard.
http://www.codeproject.com/useritems/dib_metafile.asp[^]
Roger Allen
Sonork 100.10016
This is a multiple choice question, choose wisely
Why did the hedgehog cross the road?
A: To show he had guts?
B: To see his flat mate?
|
|
|
|
|
Quick question: what is the major difference between bool and BOOL and when should I use one or the other?
- monrobot13
|
|
|
|
|
bool is a native type in C++, like int and float, and 'true' and 'false' are the only values it accepts (I believe you need to specifically cast an int, if possible at all). BOOL is generally a #define or typedef of an int, with TRUE and FALSE also being #defined
bool gives you better type checking on compilers that support it, BOOL will work anywhere but with weaker checking. if you can, use bool (VC6+ works fine with it)
|
|
|
|
|
Functionally, bool and BOOL are identical. bool should be preferred since BOOL is a legacy from a time when bool was not part of the language. It is necessary to use it with the Windows APIs, though, as I say, they are largely interchangable.
One difference though is that sizeof(bool) = 1 and sizeof(BOOL) = 4 (generally speaking).
This is particularly relevant when you need an array of boolean flags. For example,
bool lineChanged[2048];
takes 75% less memory than
BOOL lineChanged[2048];
|
|
|
|
|
bool is a true variable types just like int or float and takes values of true or false.
BOOL takes TRUE (defined as 1) or FALSE (defined as 0) or an integer value with 0 being false and non zero being true.
BOOL is a defined type of int. Therfore you can make a BOOL = int no problem and vise versa.
BOOL will aslo be 32 bits in size where as bool is supposedly only one bit in memory.
|
|
|
|
|
If your development is in the win32 environment, you should use "BOOL".
"BOOL" is a data type of win32, so we often use it. And "bool" is a C\C++ data type. If you are using a pure C\C++ compiler, you can use "bool". Now everything is ok. God bless you.
stanley
|
|
|
|
|
Im dipping my toe into the murky waters of i/o completion ports.
My app presently use threads to handle client connections , on for each connection. Naturally i now want to use i/o completion ports.
Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads.
I cant believe theres not support for this but ,as ever, the MS docs are very light on the subject.
Dave
|
|
|
|
|
Dave-B wrote:
Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads.
Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support.
|
|
|
|
|
Norm Almond wrote:
Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support.
As you state that SQL does not support overlapped read/writes, presumabley this means that IIS etc, are not truly scallable if the script uses database access  . Thats a real bummer in the real world, though as i will have to have multi threads 'hanging around' for the database to return results.
BTW thanks for your IOCP code.
Dave
|
|
|
|
|
With IOCP you have some worker-threads, normally I go for 2 - 4 four for each CPU in the machine.
If everything is running fast and not waiting for anything, your completion port only uses a single thread for each CPU, but if one of those threads is "suspended" waiting for disk I/O, a database or something else, and a new socket connection is opened, the completion port uses a new thread to handle that connection.
Basically IO Completion Ports is a mix between a threadpool and async. I/O 
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
I have a modal dialog box which has a tab control. During the dialog box's procedure I create three modeless dialog boxes for the display area of the different tabs. I used a common dialog box procedure for all three modeless dialog boxes (Q: Is this bad?). In the procedure for the three dialog boxes I call CreateSolidBrush for coloring the background of some controls. When I close the main (modal) dialog box I call DestroyWindow three times for each modeless dialog box. I process the WM_DESTROY message in the procedure for the three modeless dialog boxes and in it I call DeleteObject(hBrush). Does this cause a resource leak because CreateSolidBrush is called three times yet DeleteObject only once (even though it is the same handle to the brush) ?
|
|
|
|
|
Q: Is this bad?
On the contrary, it is the normal thing to do if the three dialog boxes look the same.
Does this cause a resource leak because CreateSolidBrush is called three times yet DeleteObject only once (even though it is the same handle to the brush) ?
Seems to me you're doing it in plain Win32 style, no MFC, right? If so, you're producing memory (or GDI) leaks, as there's only one copy of the HBRUSH object --previous brushes get lost on succesive calls to CreateSolidBrush. To avoid this, probably the simplest workaround is to have a count of how many instances of the dialog there are, initialize resources when the first one gets created and do the cleanup when the last one dies.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for the help, actually, I think I confused myself, I'll post the code for the modeless dialog procedure and maybe you can tell me if I am creating a resource leak or not?
This is the function for the three modeless dialogs:
BOOL CALLBACK InfoTabChildDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
HBRUSH hControlBrush = CreateSolidBrush( RGB(170, 170, 213) );
int iStaticWindow;
switch(message)
{
case WM_CTLCOLORSTATIC:
iStaticWindow = GetWindowLong( (HWND) lParam, GWL_ID );
switch(iStaticWindow)
{
case IDC_MOVIENAME:
case IDC_CATEGORY:
case IDC_STATUS:
case IDC_LOCATION:
case IDC_NUMBER:
case IDC_TITLE:
case IDC_YEAR:
case IDC_DIRECTOR:
case IDC_TAGLINE:
case IDC_PLOT:
case IDC_GENRE:
case IDC_ACTORS:
case IDC_LANGUAGE:
case IDC_RUNTIME:
SetTextColor( (HDC) wParam, RGB(0, 0, 0));
SetBkColor( (HDC) wParam, RGB(170, 170, 213) );
return (BOOL) hControlBrush;
}
return TRUE;
case WM_INITDIALOG:
return TRUE;
case WM_DESTROY:
DeleteObject(hControlBrush);
EndDialog(hDlg, 0);
return TRUE;
case WM_COMMAND:
switch(LOWORD (wParam))
{
case IDC_UPDATE:
_beginthread(IMDbThread, 0, NULL);
return TRUE;
}
break;
}
return FALSE;
}
For the modal dialog box, when I want to end everything I have I call DestroyWindow(); 3 times, one for every modeless dialog. If the previous hBrush(es) are getting lost with each successive call, then how do I go about keeping count of how many instances of the dialog I have? Also, am I correct in thinking that the WM_CTLCOLORSTATIC message gets called before WM_INITDIALOG? In that case maybe I should call DeleteObject(); in WM_INITDIALOG.
|
|
|
|
|
Well, you're having massive resource leaks here: Every time InfoTabChildDlgProc is called (and it's called many times during the life of a dialog box) you create a fresh HBRUSH. The way to have one and only one brush is by defining hControlBrush as static. Also, by combinig this fix with the count of instances hack, you'll ge the following:
BOOL CALLBACK InfoTabChildDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
static HBRUSH hControlBrush;
static unsigned int nCount=0;
...
case WM_INITDIALOG:
if(nCount++==0){
hControlBrush = CreateSolidBrush( RGB(170, 170, 213) );
}
return TRUE;
...
case WM_DESTROY:
if(--nCount==0){
DeleteObject(hControlBrush);
}
EndDialog(hDlg, 0);
return TRUE;
...
}Hope this helps, regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks a lot, this actually does help! I forgot about the good old static keyword. You made me a little paranoid though. In all my dialogs I have declared local variables, a lot of HWND's mostly to get a handle on controls. I don't suppose that is also creating a memory leak...right? Also, is it a good rule of thumb to declare handles that use Create... (like CreateSolidBrush) as static wherever they may be, eg. WndProc. One last question!: I am correct in thinking that WM_INITDIALOG get called once and only once, so that in my other dialogs I can call CreateSolidBrush without having to count how many instances of the dialog I have since it is only one?
|
|
|
|
|
I have two console programs. I am on a command prompt cmd.exe (fullscreen/windowed makes no diff) The simplified code is here for each program:
prog1:
main()
{
char *args[3];
args[0] = "prog2.exe";
args[1] = "abc";
args[2] = NULL;
printf("this is in prog1.\n");
_execv("prog2.exe",args);
exit(0);
}
... and prog2:
main()
{
printf("this is in prog2.\n");
getchar();
exit(0);
}
When I execute prog1, prog1 returns to the command prompt and interferes with prog2 by the input focus being on the command line. How can I keep the focus on prog2?
I can see no way around this! What can be done to keep the focus on the second running program? If I start prog1 without using cmd, it works fine, but this is not practical.
Thank you in advance ... this is driving me nuts!!!
|
|
|
|
|
Just an idea...
Try CreateProcess instead of _execv
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
thanks for your response!
However, I have tried this and have gotten the same results. whether handles are inherited, etc etc I get the same results. I am amazed that no one else has run into this problem!
|
|
|
|
|
When using CreateProcess you are returned a process handle inside the LPPROCESS_INFORMATION parameter. Use this handle with WaitForSingleObject to wait for termination of prog2.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
