Errors in quick win when opening a window

[nameiii]

I often get an error when opening a window within a quick win application. The error seems to occur at random and is hard to reproduce, but happens often enough to be a nuisance, especially as, after it has occurred, it seems to happen all the time until a reboot is carried out. The error message is:

Out of memory. File "E:\forrtl\build\qwnbuild\qwgsvid.c", line 603

and it is usually followed by:

Internal error - unexpected error. File "E:\forrtl\build\qwnbuild\qwgswc.c", line 636.

The path is not one that exists on my machine so it presumably refers to the location of the source code for the compiler. In the main I'm running Compaq Fortran 6.6, but am migrating to Intel, anda very similar error (possibly identical) also occurs under Intel Fortran 9.0.

I would be grateful for any ideas on what I can do to avoid or reduce the occurrance of this error.

Many thanks

[Jugoslav_Dujic]

Quoting - nameiii

I often get an error when opening a window within a quick win application. The error seems to occur at random and is hard to reproduce, but happens often enough to be a nuisance, especially as, after it has occurred, it seems to happen all the time until a reboot is carried out. The error message is:

Out of memory. File "E:forrtlbuildqwnbuildqwgsvid.c", line 603

There are many similar QuickWin error messages so it's difficult to say for sure. Offhand, I'd say that the most probable reason is that your SETWINDOWCONFIG tries to create a "too big" screen (combination of WINDOWCONFIG -> numxpixels*numypixels*bitsperpixel). QuickWin allocates a full bitmap for the child window image in the background, and for big screens it may easily overflow the virtual memory. You can verify it yourself if you try gradually increasing the size on your development computer.

Other than reducing window size or color depth, there's no easy workaround for that.

[nameiii]

Many thanks. Although it was failing frequently last week, it hasn't been doing so since my post!

However following your advice I've tried increasing window size (WC%NumTextCols) and can now get it to fail on demand. Reducing the size again seems to make it OK, which conflicts with previous experience (which could, I suppose, have been misleading) that, after a failure, it would fail repeatedly until rebooted.

I was opening typically 4 windows for graphics and two for text (in addition to unit 6 output) and the text windows (which are the ones I can now make fail on demand - I'm not sure which ones were failing previously) were opened with:

nCols = 1000 ! 2000 for sure failure on opening second text window (I do realise 1000 is rather large!)

Open (Unit = Unit, File = 'User', IOFocus = .false., Title = Title, RecL = nCols)

WC%NumXPixels = -1
WC%NumYPixels = -1
WC%NumTextCols = nCols
WC%NumTextRows = 200
WC%NumColors = -1
WC%Title = Title // Char(0)
WC%FontSize = -1

Status = SetActiveQQ(Unit)
If (Status /= 1) Then
Call Message('Fatal error ...')
Stop
End If

Status2 = SetWindowConfig(WC) ! if fails, should return nearest permitted values
If (.not.Status2) Then
Call Message('Error: unable to set window characteristics - nearest permitted values will be used')
Status2 = SetWindowConfig(WC) ! should set nearest permitted values
End If

Now that I can make it fail on demand, I've discovered that, when failing, both calls to SetWindowConfig fail (returning false) and generate the messages I quoted before, followed by an integer divide error (presumably when I try to write to the window).

I'm now trapping the status returned by the second SetWindowConfig which should enable a more graceful closing of the program.

If there is a way to either increase the memory available (the machine has 2GB main memory so total memory is unlikely to be the issue - or is it graphic card memory that's at issue?) or to make the limit a little more predictable I would be very interested. Also, given that these windows have only text, is there a way to keep the memory use smaller? However I guess I should just keep my windows smaller (or reduce colour depth)!

[Jugoslav_Dujic · Accepted solution]

Quoting - nameiii

I was opening typically 4 windows for graphics and two for text (in addition to unit 6 output) and the text windows (which are the ones I can now make fail on demand - I'm not sure which ones were failing previously) were opened with:

Using QuickWin windows for text output is like shooting a mosquito with a cannon. They're ill-conceived for the job, because they buffer their contents in a bitmap, rather than in a character stream rendered on demand. I don't blame you for using them, of course, because it seems all natural in the environment, but the feature badly wastes system resources. Sure they can do the job for a relatively small output set, but if you want something like a log/progress window, you'd better look for other solutions.

I don't know your requirements, but I'd rather try to put the text in a multi-line (read-only) edit control. The control itself can be, depending on your needs:

1. Contained within a modal dialog. This is the simplest, but has the obvious disadvantage that the appearance of the dialog blocks any user input outside of it.
2. Contained within a modeless dialog. This will work OK, as long as you do DLGMODAL from a menu callback (or a subroutine called from there).
3. Standalone, embedded within a child window or MDI host window. This requires more serious cludges, and use of Windows API to get through.

See here for a concept application, though the source won't help you much, being largely incompatible with QuickWin.

Multi-line edit boxes also require some tweaking to work. See e.g. http://software.intel.com/en-us/forums/showthread.php?t=40063.

[nameiii]

Many thanks - that tells me what I need to know. Whether its worth the effort to write such code for my application isn't yet clear to me though.

I must say that a good way of outputting significant quantities of text through Quick WIn in multiple windows would be very useful. Not a high priority item of course, but Intel might like to consider whether to add it to the list of possible developments (assuming it would be possible)??