Pages

12 February 2010

Every week I’m happily surprised with a kind message of someone stating his fun with GFA-BASIC 32. Some excerpts:

From a Dutch user:

“Dear Frank, I started my own company in 1982 in plastic things.

After a few years I bought a Atari 520. Later a 1024 and a 20 Mb!! harddisk.

I was interrested and bought a Bookkeeper software thing.

That thing was very slow, so I decided to write my own program.

GFA was the option and what kind of an option !!

I bought the manuals and compiler and didn't sleep many nights because I was concentraded, involved and full power.

I had to develop windows, cursor behavior, and I made myself because of all the stuff a professional bookkeeper.

I've used this program for many years and friends with a own company also, because it was able to do the depreciations automatically. The taxman never had problems with it. It was clear and understandable.

I've used it until 2001 (with Gemulator) and after that I've sold my company.

Now there are such programs with the same functions of 60Mb, mine (yours) was 93K !!!!

Love you, Henk Reinders (Holland)”

From a German user:

“Hi Sjouke,

I am still alive, no time, hard working. I am now 62 years old and may gain more time for my hobbys in a few years. I started to built up a small homepage for private use only. By the way,Iwill send you some stuff, step by step, from earlier programming. The prog wascoded by my son on aAtari 800XL, we had a lot of fun together with this machine.I presented the gfa32 version to my son on one of his birthdays. It has been very easy to transform the code.All the best for you and all gfa-fans in the future.”

Do you want to share something with the GFA-BASIC community? Leave a comment!

07 February 2010

The internal linker error caused a "File write error" when creating a stand-alone EXE or a Gfa Editor Extension GLL. The bug occured when one or more $Libraries are linked to the compiled code of the program currently editted. When none of the Lg32 libraries contained subroutines (Sub, Proc, or Func) the linker misses a pointer and reads from address NULL. The entire process of creating the output file is guarded in a Try-Catch exception handler that only reports a "File write error in filename". It doesn't specify what went wrong.
Anyway, this bug is solved in Build 1166, which you can download at http://gfabasic32.googlepages.com/update

03 February 2010

To me the Debug Output Window is the most valuable tool of GFA-BASIC 32. The Debug Output Window is controlled (wrapped) by the COM interface IDebug. I always have the debug output window open just below the main window of the IDE.

There is only one instance of the Debug object (just like Printer, Me, Win_, Dlg_, Error, App, Screen, ClipBoard, Forms, and Code4). It is not up to you to create a Debug object. As soon as you use one of the properties or methods of the Debug object, the GfaWin23.Ocx runtime checks for its existence and creates the thread global object for you.

Both Trace and Print display text in the EDITTEXT control that occupies the client area of the Debug Output Window. The central routine responsible simply sends the WM_SETTEXT message to the control. The subclass procedure of this edit control checks for an overrun of the text limit.

In addition, the central text output routine invokes the OutputDebugString() API with the same text string. The OutputDebugString function sends a string to the debugger for the current application. However, GFA-BASIC 32 doesn’t have a Win32 application debugger as meant in this context. Therefore, if the application has no debugger, the system debugger displays the string. If the application has no debugger and the system debugger is not active, OutputDebugString does nothing.

However, when you are debugging GFA-BASIC 32 in a Win32 debugger (OllyDbg, IDA Pro Disassembler, etc) you’ll see the Debug.Print text in their output windows as well.