Rapid-Q Compatibility Issues

Home
About Rapid-Q
News Archive
Download Rapid-Q
Screen Shots
View Documentation
FAQs
Compatibility Issues
Knowledge Base
Links
Code Contributions
Coding Etiquette
EZBoard Public Forum
Rapid-Q Mailing List

E-mail: William Yu

Compatibility Issues

With time permitting, I'll add all compatibilities issues to the documentation, but since Rapid-Q is still in its developmental stage (especially on the Linux/Unix side), it's hard to say if one incompatibility issue will be solved or not, therefore this lax document.

Differentiating from CONSOLE and GUI apps

Under Windows a CONSOLE application is any application which can perform both graphics as well as read and write to the standard output. This means any GUI can be compiled as a CONSOLE app without any consequences. The reverse is NOT true. Compiling a CONSOLE application as a GUI application results in a loss of any data being sent to the standard output, and may ultimately result in your program crashing.

Under Linux/Unix we have a totally bizarre case. This is mainly because I didn't want to take anything away. For example, a GUI application in Linux/Unix can write to the standard output, and read from the standard output, as long as the programmer hasn't implemented any terminal specific instructions like LOCATE or COLOR. If the user includes terminal specific statements into his/her program, that now becomes a CONSOLE application. A CONSOLE application can also do standard in/out as well as graphics with a few consequences, the terminal screen is cleared by default, and you can't run a CONSOLE application in the background (it will automatically terminate).

The Main Form

There is no differentiation between forms when working with the Windows version. However, under Linux/Unix, the first form you DIM ultimately becomes your main form (even if it isn't the first form you SHOW). What this means is if you close your main form, this also terminates your application. When the main form is closed, your program terminates, this means any code you have written after that point will not be executed. This only applies to the Linux/Unix version of Rapid-Q.

Component resizing

With the Windows version, you have to manually resize all your components when your form resizes. You do this with the OnResize event. Under Linux/Unix, the components on your form automatically resizes when your form resizes. Also make sure to define the size of your form before adding any components to it. This is most crucial for the Linux/Unix version. If you don't do this, your components may appear too big/small.

Creating Menus

A Menu in Windows is a list of menu items attached to a QMainMenu component. Not to confuse people anymore, but the Linux/Unix version does not exactly have a QMainMenu component. A menu bar is a singular menu with dropdown items. This means you can only add to the menu bar, and not to the menu items. Rapid-Q just strings menu bars together at the top of the screen, and provides dropdown lists when you click on it. What this means is that you must create your menu bars first, then you can add to it. Since I know I've confused everyone by saying this, I'll provide an example:

      CREATE Form AS QForm
        CREATE MainMenu AS QMainMenu
          CREATE FileMenuBar AS QMenuItem
             Caption = "File"
          END CREATE
          CREATE EditMenuBar AS QMenuItem
             Caption = "Edit"
          END CREATE
          CREATE SearchMenuBar AS QMenuItem
             Caption = "Search"
          END CREATE
        END CREATE
      END CREATE

      DIM OpenItem AS QMenuItem
          OpenItem.Caption = "Open"

      FileMenuBar.AddItems OpenItem

It's no different than what you'd do for the Windows version, but notice that you don't add directly to the MenuBar until after you declared them. FileMenuBar is considered a MenuBar, which you can add to, OpenItem is considered just an item, which cannot be added to. The OnClick event handler does not apply to the MenuBar, just the item. Again, this only applies to the Linux/Unix version, you're free to go wild in the Windows version. Please note that the GTK version is less strict.

INKEY$ support

Complete INKEY$ support is provided in the Windows and Linux/Unix version. There are some issues you may want to know about, for one, an extended key occupies 2-bytes (nothing new there), however, the first byte is not NULL (ie. CHR$(0)). The first byte is actually an escape character, CHR$(27). The next character you can parse as normal.

          A$ = INKEY$
          IF A$ = CHR$(27) + "H" THEN
            PRINT "Up Arrow Key Pressed."
          END IF

The Windows version can trap a few more extended keys than the Linux/Unix version, but these keys aren't processed by default. Please see Chapter 3 of the Rapid-Q Documentation for more on the $OPTION INKEY$ directive.

QSocket ReadLine & WriteLine

QSocket now has the exact same functionality between the 2 versions.