|
How does a normal command prompt open? I've never seen this problem before, but it is probably some screwed setting on the command prompt? Are you upto date with all the service packs, both VC and Windows?
Michael 
|
|
|
|
|
Hi Michael
apparently my Win2K has been set to open all console apps in fullscreen mode by default, hence the black screen (this was pointer out to me by Michael Dunn). It's described in Q126031 in MSDN KB. I simply removed this default fullscreen mode in the registry and the problem evaporated!
Thanks for all your help
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
I had the same problem a long while ago. As I remember, I reinstalled visual.
Problem was caused by Visual installation which was not full. Something was missing and visual tried to get it from CD.
Hope this helps
|
|
|
|
|
What happens is the IDE launches cl to do the compiling. cl is a console app, so you're seeing the console window. I know I've seen a KB article on this, give a search of MSDN on "cl console" and you should find it.
--Mike--
http://home.inreach.com/mdunn/
#include "witty_sig.h"
![Heart | [heart]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/love.gif) your ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) with ![Good Stuff | [The good stuff]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/vegemite.gif) and ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
Wow! You're absolutely right. The KB article is Q126031. The problem was that my Win2K was set to start console apps in default fullscreen mode. When I remobed this setting in the registry the problem evaporated!
Thanks 1M times!
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Hi guys !!
I have to do this.
On my terminal server, i need to shared the process doing the communication (outside to the control pannel).All other connected(logged) user must see the shared memory created by this process (attach to it).
In resume, in my app i have a process doing the communication with the control pannel. When i start the app, the process bind some port. My problem is on the terminal server (because some Unix client whant 2 see the data) many user can start their own session but when they open the app, the process popup an error message causing by the communication port already open. My solution, create only one process stay open forever and share the data. How i can do this ?
I try with some CreateFileMapping(); ... in the task manager i see the process running but i cannot attach 2 the shared memory. Can someone explain this 2 me?
Regards,
Vincent Filion.
vincent.filion@cae.com
If you whant more details send me a mail.
|
|
|
|
|
Does anyone have any tips on increasing the performance when building large apps - especially the link cycle. I have a few large projects that seem to be taking longer and longer to build. I have a 700Mhz Dell laptop with 256MB of RAM and plenty of disk space free (~4GB) - any tips?? (a new PC is out of the question ... )
|
|
|
|
|
If you're running a Virus Scanner, turn it off.
If you have browser info turned on, you could turn that off.
The bottleneck during a compile is the speed of your hard drive. A crap-load of temporary files are created, not to mention an obj and sbr file for each CPP file in your project. Since all these files go to the hard drive, that's where you have to focus your attention. If you're not already using one (and if your motherboard supports it), get an ATA66 or ATA100 drive (and the necessary cables of course).
I don't know if this matters, but I have the compiler, the temp folder, and my source code all on different drives, and Everything moves right along in terms of speed.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Does anyone have any tips on increasing the performance when building large apps - especially the link cycle.
Is your app a monolithic .exe, or you've split the functionality into multiple .dlls?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Pretty much a monolithic EXE but I have created .libs for a lot of robust code that rarely needs to change.
|
|
|
|
|
So linker has lots of work to do - it has to copy the stuff from static .libs to your .exe. Of course, this reduces the work for compiler. You may consider moving parts of the app to .dlls - in such case, the linker doesn't copy the function bodies, only creates the references to .dll in the file.
Are you running MSDEV.EXE with /Y3 option? What are the exact times of compile and link?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I will experiemtn with using DLLs instead of static LIBs and see if this improves performance.
What will the /Y3 option do for me?
|
|
|
|
|
What will the /Y3 option do for me?
It displays the compile/link times in the output window.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Are you using incremental linker (for your debug builds)? It may be slower the first time but it should be faster afterwards if only few files have changed.
Also, you could verify that linker options and disable some of them in you debug builds.
Also, a tip is too avoid running other disk intensive application at the same time. This effectively could increase link time a lot.
And limit the debugging informations in file where it is not so usefull. Probably for many files, line information will suffice and linking an application without much debug information could be much faster.
Philippe Mori
|
|
|
|
|
Challenge: How do you determine the physical dimensions of your pixels/monitor?
There must be a smart way of determining the real size of a pixel, or at least figuring out the width:height ratio!
I can't believe that information has not been stored with the video driver but unfortunately it seems to be the case.
Does anyone know of some clever way to work out the physical monitor view dimensions? Implicitly this could mean working out the real pixel size, pixel ratio, pixels per inch...
I know there's information to retrieve using GetDeviceCaps but they are for some strange reason fix values. They don't change!!! Why is that?
There's a huge prize waiting for you if you accept and solve this quiz/challenge... Well, not really, but I'd be very grateful!
And measuring the screen by hand does not count!
/Tommy
|
|
|
|
|
I don't think you can get 'real' sizes. The way to calculate pixel ratio and draw rulers with inches/centimeters is to use GetDeviceCaps with LOGPIXELSX/LOGPIXELSY.
I know there's information to retrieve using GetDeviceCaps but they are for some strange reason fix values. They don't change!!! Why is that?
Probably it's because video driver doesn't care if monitor has 15 or 49 inches  And imagine a CRT projector connected to your graphics card which displays an image on the wall. In this case, these values would depend on the distance between the device and the wall  Your machine would have to be equipped with some sonar system.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Ok, that's what I thought... But are you saying that you can create rulers in inches/centimeters using the LOGPIXELSX/Y? Ok, you can create them but they will not reflect the real size on screen right?
Intuitively it feels like there's a solution to this... just gotta get someone to find it!
/T
|
|
|
|
|
Ok, you can create them but they will not reflect the real size on screen right?
Exactly. That's why the parameters you pass to GetDeviceCaps are called 'logical' pixels, not 'real' pixels. One more reason for that: you have controls in your monitor for adjusting the width and height of actual picture displayed on the screen - your graphic card is of course unaware of these adjustments.
If you find any program that draws rulers using *real* centimeters/inches, let me know
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Try these functions:
void MyFunc(CDC* pDC)
{
int logx = pDC->GetDeviceCaps(LOGPIXELSX);
int logy = pDC->GetDeviceCaps(LOGPIXELSY);
int nMM = 100;
int nPixelsX = MmToPixels(nMM, logx);
int nPixelsY = MmToPixels(nMM, logy);
}
int MmToPixels(int mm, int LogPixels)
{
return ((int)((long)mm * LogPixels / 25.4));
}
int PixelsToMm(int Pixels, int LogPixels)
{
return (int)(Pixels * 25.4 / LogPixels);
}
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
To determine the "viewable area", get the horizontal and vertical resolution windows is currently set to, and convert those pixel values to millimeters (using the PixelsToMm function). If you need it in inches, it is a simple matter to convert mm to inches, and there you have it.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Well, I appreciate your help, but the result is not real size...
For instance, GetDeviceCaps(LOGPIXELSX/Y) returns a value that is fixed and doesn't depend on any physical settings made on the monitor or even changes made in resolution and physical monitor size. If it would, then everything would have been fine.
Try for your self and measure your screen.
/T
|
|
|
|
|
Hi!
I've been trying to send keystrokes from say Window1 to Window2. It's easy when Window2 is the active one. However, I want to send it keystrokes even when it's not the active window. The code I've written for Window1 looks like below:
PostMessage(hWnd, WM_KEYDOWN, VK_CONTROL, MAKELPARAM(0x1, MAKEWORD(MapVirtualKey(VK_CONTROL, 0), 0x00)));
PostMessage(hWnd, WM_KEYDOWN, 'B', MAKELPARAM(0x1, MAKEWORD(MapVirtualKey('B', 0), 0x00)));
PostMessage(hWnd, WM_CHAR, 'B', MAKELPARAM(0x1, MAKEWORD(MapVirtualKey('B', 0), 0x00)));
PostMessage(hWnd, WM_KEYUP, 'B', MAKELPARAM(0x1, MAKEWORD(MapVirtualKey('B', 0), 0xC0)));
PostMessage(hWnd, WM_KEYUP, VK_CONTROL, MAKELPARAM(0x1, MAKEWORD(MapVirtualKey(VK_CONTROL, 0), 0xC0)));
The problem seems to be this - Window2 has 'Ctrl-B' defined as an accelerator. So, when one actually presses 'Ctrl-B' in Window2, the TranslateAccelerator function in Window2 translates the keystrokes to WM_COMMAND message. However, when the same keystroke sequence is sent programmatically, it doesn't get translated to WM_COMMAND.
Can someone help me out with this please.
Vijay Chauhan
|
|
|
|
|
Try to use
keybd_event()
or
SendInput()
Eventually try to activate application first.
|
|
|
|
|
Thanks, but I've already tried using SendInput. However, I don't really want to activate the other window before sending it the keystrokes. I want to continue working with the current window, while simultaneously updating the other window, even if it's minimized.
|
|
|
|
|
Hi,
I have a connection to an active Internet explorer window, where I call the Navigate2 method to download a http page. After calling this navigate method I would like to stop the current thread processing and wait for the web browser to completely download the page.
I currently have the following code,
m_webBrowser.Navigate2(URL);
while(m_webBrowser.GetBusy())
{
DWORD res = WaitForSingleObjectEx(m_webBrowser.GetBrowserWnd (),20000,TRUE);
}
but the method GetBusy() of web browser returns false after only a couple of milliseconds, but I know full well that the page is not yet downloaded. Also the function WaitForSingleObjectEx returns in a complete state.
What I woul ideally like to do is stop within this while loop and wait until the web browser has completely loaded the page, where I can then call the GetHtmlDocument method.
Any ideas
Thanks
CAB
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
