Clear screen function...

[GypsyPrince]

I have a possible easy one for you Pros...

I need a console clear screen procedure similar to "cls()". I want my app to display some columnar data in the console window. Then, when the user presses a key, it will clear the screen and post a whole new set of columnar data to the console window. This will be repeated for how ever many times corresponds with the existing number of data sets.

What I have come across so far is ClearConsole(). However, this procedure seems to only work correctly if I enable the graphics mode using EnableGraphicalConsole(1), which isn't a problem. However, I want to be able to test if the graphical mode is already on so that I can turn it back off if it is not supposed to be on. Take a look at the pseudo-code for my half-ass wrapper function below.

Procedure cls()
If GraphicalConsole = 1 ; if graphical mode is on
ClearConsole() ; clear console screen
ElseIf GraphicalConsole = 0 ; if graphical mode is off
EnableGraphicalConsole(1) ; temporarily turn graphical mode on...
ClearConsole() ; clear console screen...
EnableGraphicalConsole(0) ; turn graphical mode off again...
EndIf
EndProcedure


What would I use in my real code to test whether graphical mode is on, where the "If" and "ElseIf" line are? I've already tried my wrapper function without testing and it works great. But, I need to test whether or not graphical mode is on. If anyone can help me here it will be greatly appreciated. Also, suggestions for a more efficient method of achieving the same goal will be appreciated as well.

Regards,
Gypsy

[bbanelli]

Maybe try something like this? It should work on all platforms...

Code: Select all

CompilerIf #PB_Compiler_OS = #PB_OS_Windows
  ImportC "msvcrt.lib" 
    system(str.p-ascii) 
  EndImport
CompilerElse
  ImportC ""
    system(str.p-ascii) 
  EndImport
CompilerEndIf

OpenConsole()
PrintN("1234")
PrintN("4321")
Delay(2000)
CompilerIf #PB_Compiler_OS = #PB_OS_Windows
  system("cls")
CompilerElse
  system("clear")
CompilerEndIf
PrintN("new things...")
Delay(1000)
CloseConsole()

[GypsyPrince]

Very interesting...

I did something quite similar to this a couple of years ago in C. It tests for the OS platform and implements the correct clear screen procedure accordingly. However, after much valued input from some C gurus, I learned that using the Windows system("cls") command posed a backdoor security risk to the user's system. I finally wound up using the API for the Windows part of the cls() procedure. It required about 20 extra lines of code, but was actually a bit faster than system("cls") and I felt a lot more secure using it.

[bbanelli]

Very interesting...

There are probably more sophisticated methods but for clearing the screen in simple application, honestly, who would care?

I did something quite similar to this a couple of years ago in C. It tests for the OS platform and implements the correct clear screen procedure accordingly. However, after much valued input from some C gurus, I learned that using the Windows system("cls") command posed a backdoor security risk to the user's system. I finally wound up using the API for the Windows part of the cls() procedure. It required about 20 extra lines of code, but was actually a bit faster than system("cls") and I felt a lot more secure using it.

Never heard of something like having a "security vulnerability in cls". Do you have any reference for that one? I would highly doubt that "cls" command has any sort of (at least efficient or sane) security issues...

[luis]

Never heard of something like having a "security vulnerability in cls". Do you have any reference for that one? I would highly doubt that "cls" command has any sort of (at least efficient or sane) security issues...

He probably means system("something") in general -> http://linux.die.net/man/3/system

Apart what mentioned there, there is the idea you are not really sure about what you are executing.

[GypsyPrince]

The way it was explained to me by seasoned professionals is that you never hard-code any system("blah-blah-blah") calls into your applications.
Some person with sinister motives who knows that your program makes system calls to existing Windows programs could replace one of those programs with a virus, and when your program calls it, you get the blame.

Example: I write a program that calls system("calc.exe") which uses an executable file name or internal command to launch a program, whereas the API uses internal control registers rather than an executable filename. If some idiot replaces the calc.exe that ships with Windows with a calc.exe which has a virus in it, then when my application launches that program I get blamed for the virus. However, if I launch the calculator program through the API, the control registers for the virus program won't match those of the legitimate calculator program that are stored in the registry, and the virus program won't load.

[GypsyPrince]

but, back to my main point...

Is there any procedure or method that I can test to see if graphical mode is already enabled or not?

[Demivec]

Is there any procedure or method that I can test to see if graphical mode is already enabled or not?

No. It has been requested, possibly several times.

You would have to track the state yourself. Since you are setting it that isn't a real problem.

Here is my current approach:

Code: Select all

Global GraphicalConsoleState = 0
Procedure SetGraphicalConsoleState(state)
  Protected previousState = GraphicalConsoleState
  If state
    GraphicalConsoleState = 1
  Else
    GraphicalConsoleState = 0
  EndIf
  EnableGraphicalConsole(GraphicalConsoleState)
  ProcedureReturn previousState ;return the previous state so that it can be restored later
EndProcedure

Procedure GetGraphicalConsoleState()
  ProcedureReturn GraphicalConsoleState ;return the current graphic state without changing anything
EndProcedure

Procedure cls()
  state = SetGraphicalConsoleState(1) ;save current state and make sure graphical mode is on
  ClearConsole()                      ;clear console screen...
  SetGraphicalConsoleState(state)     ;restore previous state
EndProcedure

[GypsyPrince]

Never mind...

I wrote my own API wrapper function using GetConsoleMode(). Problem solved.

[bbanelli]

Apart what mentioned there, there is the idea you are not really sure about what you are executing.

Example: I write a program that calls system("calc.exe") which uses an executable file name or internal command to launch a program, whereas the API uses internal control registers rather than an executable filename. If some idiot replaces the calc.exe that ships with Windows with a calc.exe which has a virus in it, then when my application launches that program I get blamed for the virus. However, if I launch the calculator program through the API, the control registers for the virus program won't match those of the legitimate calculator program that are stored in the registry, and the virus program won't load.

Following that line of thought, who guaranties that polink.exe is "legitimate" and not "replaced by some idiot with virus"?

There are plenty of reasons I can think of why not using system(), but this one is simply not the proper one...

[GypsyPrince]

Issue is resolved. Thanks for everyone's input.