C / C++ / MFC

Michael P Butler7-Nov-01 2:43

Michael P Butler

7-Nov-01 2:43

At a guess this is VC making a call to the command prompt to run a tool of some kind. Try changing the background colour of your command prompt and see if the same background colour appears in the compiler.

Michael Smile | :)

Steen Krogsgaard7-Nov-01 3:42

Steen Krogsgaard

7-Nov-01 3:42

You're right, of course. I found out that during a long compile I could switch away from the black screen using alt-esc, and briefly see a command prompt icon flicker on the task bar. Now the question is, why doesn't the focus return to the IDE window during the compilation, but stays on the command prompt window until the compile is finished? I have checked a number of flatscreen monitors as well as normal CRT ones, and they all displayed this phenomenon. So it has nothing to do with the monitor, perhaps my updated Intel Graphics Technology driver is to blame? Or did I inadvertently set some default parameters for command prompts in a special way to get this? I, for one, am completely lost here.

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"

Michael P Butler7-Nov-01 4:21

Michael P Butler

7-Nov-01 4:21

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 Smile | :)

Steen Krogsgaard8-Nov-01 1:15

Steen Krogsgaard

8-Nov-01 1:15

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 Smile | :)

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"

Mukkie7-Nov-01 8:06

Mukkie

7-Nov-01 8:06

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

Michael Dunn7-Nov-01 8:06

Michael Dunn

7-Nov-01 8:06

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]

your

with

and

Steen Krogsgaard8-Nov-01 1:17

Steen Krogsgaard

8-Nov-01 1:17

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! Smile | :)

multiple session

7-Nov-01 1:29

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.

Confused | :confused:

MSVC6 performance tips?

Rob Caldecott7-Nov-01 1:19

Rob Caldecott

7-Nov-01 1:19

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 ... Smile | :)

)

#realJSOP7-Nov-01 1:25

#realJSOP

7-Nov-01 1:25

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

Tomasz Sowinski7-Nov-01 1:34

7-Nov-01 1:34

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

Rob Caldecott7-Nov-01 2:00

Rob Caldecott

7-Nov-01 2:00

Pretty much a monolithic EXE but I have created .libs for a lot of robust code that rarely needs to change.

Tomasz Sowinski7-Nov-01 2:19

7-Nov-01 2:19

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

Rob Caldecott7-Nov-01 2:24

Rob Caldecott

7-Nov-01 2:24

I will experiemtn with using DLLs instead of static LIBs and see if this improves performance.

What will the /Y3 option do for me?

Tomasz Sowinski7-Nov-01 3:00

7-Nov-01 3:00

What will the /Y3 option do for me?

It displays the compile/link times in the output window.

Tomasz Sowinski -- http://www.shooltz.com

Challenge: How do you determine the physical dimensions of your pixels/monitor?

Philippe Mori7-Nov-01 3:32

Philippe Mori

7-Nov-01 3:32

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

Tommy H D Svensson7-Nov-01 1:09

Tommy H D Svensson

7-Nov-01 1:09

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! Smile | :)

And measuring the screen by hand does not count! Smile | :)

/Tommy

Re: Challenge: How do you determine the physical dimensions of your pixels/monitor?

Tomasz Sowinski7-Nov-01 1:19

Re: Challenge: How do you determine the physical dimensions of your pixels/monitor?

7-Nov-01 1:19

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 Big Grin | :-D

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 Wink | ;)

Your machine would have to be equipped with some sonar system. Smile | :)

Tomasz Sowinski -- http://www.shooltz.com

Tommy H D Svensson8-Nov-01 22:50

Tommy H D Svensson

8-Nov-01 22:50

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! Smile | :)

Re: Challenge: How do you determine the physical dimensions of your pixels/monitor?

Tomasz Sowinski8-Nov-01 23:03