Some problem with that distribution, or the packages you installed.

User programs shouldn't be able to bring down the system under Linux.

I have FC2 (with prelinking and exec-shield enabled) and the programs work just fine. I'm using fpc-1.9.4.

Tried to press Ctl-Alt-F7 to get back to the X11 window? I've had some old graphics programs switch to a text terminal window.

John

Fedora core II. My programs seem to take over the whole screen and when they finish the system is stuck. Linux doesn't come back. I have to reboot every time. There are no loops.. just hitting "END.".

Any suggestions?

Do you call closegraph? I'm converting Turbo code... probably making some mistakes....

Thanks, I'll try that!

The clrscr function seems to be the culprit. When it hits that it clears the screen, puts up an old pong-style mouse cursor, and I can't get back to Linux. I don't think it's switching to graphics mode. Just some text mode like you suggest.

Jeff

Ctrl-Alt-F7 works.

Then I tried the maze sample and it comes back. So I'll figure out what it's doing differently.

Thanks, everyone.

Jeff

Hi Jeff...

Getting the graph thing to work is delicate (to say the least). Please take into account you have to use the special hi resolution constants for the display... Such things as 'm800x600' for the modes. In the reference manual for the graph library you'll find more on that (Check 'A word about mode selection').

I more or less gave up on using graph - it's a bit of a headache to have the video switch modes, particularly while debugging. I don't know if there is a more elegant solution, apart from trying to open a new window with a gnome-canvas in it or so.

John

The best solution would be an SDL-based graph unit, I think. Nobody's working on that though, afaik.

Jonas

Hi Jonas.

I did a 'client-server' type of thing. On the Pascal-side it looks like a Graph-compatible library. But instead of switching modes, it starts a new window, with a gnome-canvas in it. The 'graph' lib then sends its graphic commands through a pipe to the new window.

It is far from usable (many things are missing) but the idea has several pluses (in my opinion):

1) The 'remote graph' can be called from other programs as the interface is just the pipe. I could even be called from bash... (never tried)

2) The gnome canvas has nice anti-aliased graphics, and the resulting plots _do_ look very nice.

As I said, it is far from complete (eg. no fonts yet) and not very stable either. One thing I haven't found yet is a way to save the gnome-canvas to a graphics file (I just made screen shots).

With the experience I had later with gnome-print library, I could image that this could also be combined somehow.

Is there interest in this?

John
------

That person simply says he used those units in TP7. There are no such units for FPC.

Jonas

Anyone ever use this unit? Just wondering if it works better....

http://www.cg.tuwien.ac.at/~knapp/graphix_old/gxhome.html

Jeff

Code here :

http://community.freepascal.org:10000/bboard/q-and-a-fetch-msg.tcl? msg_id=0000qd&topic_id=14&topic=Developing%20for%20Windows

shows units called BGIDriv and BGIFont.

Is this true, do they work and how do I get them?

Gracias!

Jeff

Multiple possibilities

- Both graph and crt might interfere both try to capture output. (graph via linking in svgalib?)
- The console you use might also matter. Is it framebuffer, normal console, a terminal emulation under X?

Try to reproduce the problems with a small program using Crt only on a normal (non X console).

I'm using the following units on Linux.

USES ports, dos, crt, graph, printer;

readkey doesn't capture keystrokes as they're typed. It reads them all in sequence only after the user presses enter. This is unlike the way TP reads the kbd buffer.

Am I doing something wrong? And Linux terminates kbd strings with LF. So I guess I need to account for that. I'm converting a program which checks for CR to back up one level on a menu. Pressing the enter key returns LF instead.

But my main question is how to read the kbd buffer as keys are typed.... not after the user presses enter. readkey doesn't do the job.

Thanks!

Jeff

Yes.
SVGALib also offers keyboard handling, which is not compatible with CRT. There is little we can do about that.

But: You may want to try to reseverse the order of Graph and CRT in the uses clause. In that case, CRT will be initialized last, and will set the terminal in the proper mode for CRT to function correctly.

It may confuse svgalib's keyboard handling, though. But as you will probably only be using CRT routines for that, this should not matter.

Michael.