Hi everybody,

I have couple of questions and suggestions, concerning the Win32 'Graph' unit:

Is there a way to change the 'mainwindow' properties after the 'InitGraph' call?

I would like to change the icon and to make the window non resizable. I tried
couple of things, but nothing seems to work. In my opinion it would be better if
the window was not resizable by default, since most of the old 'Graph' applications
do not expect the screen to change its size. And if someone wants to write an app,
that uses resizable window, it could be easily done through the 'graphwindowstyle'
constant.

Also there should be a way to change the default icon to, for instance, some icon in
the resource file, before the 'InitGraph'.

I want to point out, that the closing of the main window does not quit the application, and I think that there should be a mechanism that would halt the app
on 'wm_destroy' message. There should also be a handler for the 'wm_close' message, that could prevent unexpected closing of the program.

And finally, 'wincrt' does not recognize the Alt+SomeKey combinations.

Hope I don't nag too much :-)

Milos

Milos Pejovic wrote

I would like to ... make the window non resizable.... In my opinion it would be better if the window was not resizable by default, since most of the old 'Graph' applications do not expect the screen to change its size.

Better yet, continue to allow it to be resizeable, but if it is reduced, provide scrollbars to access the "virtual canvas" of the original size, onto which the Graph calls draw their image.

- Rich

Milos Pejovic wrote

Also there should be a way to change the default icon to, for instance, some icon in the resource file, before the 'InitGraph'.

It is possible to change the icon of a 'graph' fpc-program. Read in the 'programmers manual' chapter 12, 'Using Windows resources'.

Additional information:
For using an icon, you must define {$APPTYPE GUI} and then put the command 'ShowWindow(GetActiveWindow,0);' before the 'InitGraph()'.

Hi Andreas,

It is possible to change the icon of a 'graph' fpc-program. Read in the 'programmers manual' chapter 12, 'Using Windows resources'.

Yes, but that is only for the app icon display in Explorer, and I meant to change the icon of the 'mainwindow' system box.

Additional information: For using an icon, you must define {$APPTYPE GUI} and then put the command 'ShowWindow(GetActiveWindow,0);' before the 'InitGraph()'.

This doesn't work on my fpc-1.0.6, i.e. it still shows the default 'idi_Application' icon. Frankly, I don't know how to accomplish this without the changes in the windows 'graph' source...

Cheers,
Milos

What does the fpctris demo do on your system ? Does that one hide the dos window?

While we're on the subject...

Can I accept keyboard input while the graph window has the focus?

I ported (from Borland Pascal) a Graph application that displays a graph and then accepts keyboard input via the CRT unit's functions Keypressed and ReadKey, based on which it modifies the graph. When I compile and run my app under Free Pascal for the Win32 target, the graph window opens up, but the keyboard is ignored unless the user switches the focus back to the console window from which the app was launched. This is awkward because the user has to remember to do it, and then the console window partially obscures the graph. I would prefer to read the keyboard directly while the graph window has the focus, but how?

- Rich

Rich Pasco wrote

Can I accept keyboard input while the graph window has the focus?

Try to use WinCRT instead of CRT.

Hi,

What does the fpctris demo do on your system ? Does that one hide the dos

window?

It does hide it, but that is what the {$APPTYPE GUI} does :-)

On closing of the main window fpctris doesn't quit also. It needs to be killed manually. There should really be some code to handle this. I suggest to put the handler to wm_close in the graph unit, that would do 'CloseGraph; Halt;' by default, and to make it possible somehow to override this, if we do not want the app to quit without performing some checking.

Is it possible that the window doesn't change the icon, the way Andreas told me, because I have put {$MODE TP} to overcome some errors?

Cheers,
Milos

> What does the fpctris demo do on your system ? Does that one hide the dos window? It does hide it, but that is what the {$APPTYPE GUI} does :-)

Odd, since here it really detaches from the console, just like e.g. notepad. (Win98SE and Win2000)

On closing of the main window fpctris doesn't quit also.

If I press ESC in the main screen, everything is gone.

No, I don't think so.

I am working on such a unit,
for fvsion win32 graph support.

What it basically does is to translated
graphic mode system messages
like WM_KEYDOWN, or WM_LBUTTONDOWN and so on
into INPUT_RECORD that I push in the
input handle of the Console.

The problem is that the current version requires to modify the win32 graph unit...
But otherwise it does work...

You can get the unit called win32gr.pas
in the fvision CVS repository.

The RTL changes are not yet commited :(

In response to my query,

Can I accept keyboard input while the graph window has the focus?

Andreas K. Foerster wrote,

Try to use WinCRT instead of CRT.

Thank you, Andreas, that worked perfectly.

New question: Other than asking here, how would I have known that from the documentation? In the manuals that came with 1.0.6, file units.pdf does not mention only mention I could
find was in user.pdf where section 9.3 says,

wincrt This implements a console in a standard GUI window, contrary to the crt unit which is for the Windows console only.

I don't understand what this means. The following program:

  uses WinCRT;
  begin
    WriteLn('Hello world!");
  end.

compiled for Win32, behaves identically to its counterpart with "uses CRT" instead, when launched from a shell command prompt.

So what does the comment in units.pdf really mean? I wonder if, in the next version, the documentation could expand on it a little bit?

Thanks again,

- Rich

Well, it's not quite as simple as substituting WinCRT for CRT, because WinCRT is missing a number of the functions available in the CRT unit. The missing functions include, to name a few:

ClrEOL, CursorBig, CursorOn, GoToXY, WhereX, WhereY, WindMax, WindMin, Window ...

I suppose that I can "mix and match" by using both CRT and WinCRT, but I feel like I'm in uncharted territory here. Are there any documents that would help?

- Rich

These functions make only sense in a console application.

WinCRT is not meant as a full replacement of the Crt unit, but as a workaround for gui applications.

I suppose that I can "mix and match" by using both CRT and WinCRT,

You have to choose, wheather you want to write a console application or a gui application.

but I feel like I'm in uncharted territory here. Are there any documents that would help?

Do you really need both in the same program?

Rich Pasco wrote

I suppose that I can "mix and match" by using both CRT and WinCRT, but I feel like I'm in uncharted territory here. Are there any documents that would help?

You could try it like this:
c1 := CRT.ReadKey;
c2 := WinCRT.ReadKey;

You should then always use the unit name.
If you don't, it uses that unit, that comes later in the unit clause.

The danger is more that the initialisation code of both units do the same things and are mutually exclusive.
(which is pretty much the same problem as Jonas said about using Crt and Graph on Linux)

Hi all,

Odd, since here it really detaches from the console, just like e.g.

notepad.

(Win98SE and Win2000)

I use Windows ME, but in fpctris source there is:

{$ifdef UseGraphics}
 {$ifdef Win32}
   {$define Win32Graph}
   {$APPTYPE GUI}
 {$endif}
{$endif}

So it doesn't detach from console, if it is meant to be a windows graph app...

> On closing of the main window fpctris doesn't quit also. If I press ESC in the main screen, everything is gone.

I see that I will have to be more persuasive :-)

Writing a console app under Windows is Ok, as it is to write a gui app, but I think that writing a gui app that detaches from console brakes some conventions. It is okay under Linux, but mixing it under Windows will confuse the users, who are not used to this.

First of all, 90% of the Windows users will try to hit the 'X' to close the app, and then what? Should we write in console: 'Close this window too'? I know you could just hit ESC, but we should prevent the users from doing something stupid. As I recall, the GGI demo under Linux could not be closed with the click on the window close button.

The fact is that the end users will expect their M$Win program to behave like one, no matter it was originally developed under Turbo Pascal for Dos. And that includes at least: the closing 'on X', different window icon for each app, and no other windows except the main one. This also goes for other fpc targets, like BeOS.

We have to be people-centric, when writing apps, since we (mostly) do not develop for each other. I could be perfectly happy with the Linux with bash, fpc, gcc and svgalib only, but there are many folks, that are really not familiar with computers, so we should help them use the 'mean machine' by developing user friendly apps using our favourite Pascal compiler, under all CPUs and OSes. And the world will be a better place ;-)

Anyway, keep up the good work the fpc team!

Cheers,
Milos

P.S. I tried to compile the latest 'graph' unit from the cvs, with some minor changes I made, but I get the following 3 errors, among many notes and warnings:

509 / 29 modes.inc
Error: Unknown record field identifier SETALLPALETTE 510 / 23 modes.inc
Error: Wrong amount of parameters specified
510 / 36 modes.inc
Error: Unknown record field identifier SETALLPALETTE

What did I do wrong?

I tried

  uses CRT, WinCRT;
  var c1: char;
  begin
    Window(...);
    c1 := ReadKey;
  end;

but the call to ReadKey never returned, no matter how many keystrokes I hit.

- Rich