Graphics - loss of colour

I have aprogram that produces run-time grphics, plotting variable values as the run progresses. It has been in use for many years, linked into several different codes.

When I last compiled the codes (mid-Jiuly) the graphs were coming out in many different colours, as expected. Since yesterday. when I recompiled, all the lines come out blue. The old executables still produce coloured lines. These results are repeatable when I run the executables on another machine.

I have used the debugger to check the colour code being passed to the line plotting routine and it takes all the expected values.

Any ideas on what may have happeneed?

The default colour mode for %gr has been changed from vga_colours to rgb_colours so you may need to add vga_colours to your %gr options.

The program I am running does not use %gr

I have tried adding CALL set_rgb_colours_default@(0) to the first graphics routine called, but the routine cannot be found.

I have not changed the compiler since May. The problem arose in July. Wouldn't this change in default colour system have affected thing from May?

Can anything have been changed on the computer that could cause this problem? Mid-July executables still plot in colour.

The change to the default colour mode is reflected in salflibc.dll. So if you have not changed this DLL (nor inadvertedly accessed a different one) then there should be no change in this respect.

SET_RGB_COLOURS_DEFAULT@ can be found (for example) in the INCLUDE file clearwin.ins.

I have had an earlier version of the compiler on my computer, so there is potential for the wrong dll to be picked up (although I don't know why this should suddenly happen). I have uninstalled and reinstalled the compiler, but I still have the problem.

The dll sits in C:\Program Files(x86)\Silverfrost\FTN95 Is there anywhere else it should be? What is the search heirarchy?

The dll is required when the program runs. So is it the version it fiinds at run time that affectrs the colours or is it the version that is picked up during compilattion?

The supplied application called SALDIAG.EXE can be used to search for the DLL.

For testing purposes you could copy the DLL to the local folder and run your exe from there.

I added some code that I found on the forum. It reports that my program is accessing the latest dll from the location I gave above.

I had already tried copying the dll to the working directory, but ithe program still gave the reported problem.

Is it possible to reproduce the problem in a small program for us to look at?

I'm not sure whether I could split it apart easily. The graphics is embedded in code that I am not very familiar with. I'll think about this.

A colleague installed the compiler tempoarily on another machine that had not had any previous versions on it. The same problen occurred so it can't be to do with oicking up a previous dll. It also rules out me havung inadvertantly changed some compiler settings.

It eems that I don't even have to recompile a program to get the problem - relinking is enough.

I have created a new executable from an old (May 2014) set of object modules. The May executable gives coloured gphics and the new one only blue.

As I reported above the problem began in the lattr half of July with no change in compiler.

I have had exactly the same problem as Catherine What had been coloured graphs suddenly came out as all black. I inserted: use_rgb_colours@(handle,BOOL) with handle=0 and BOOL=1 immediately after calling %gr to create a graphics box All lines and symbols reverted to colours as before.

If Catherine isn't using %gr, then she must be using %og or %dw. If she used %og, then she isn't using the GDI, is she, so she should be unaffected by whether VGA or RGB is the default.

My bet is that the change to RGB as the default is at the root of this for %dw windows. (Or maybe simpleplot ones).

The date looks right to me. Is it item 345 in the ClearWin+ enhancements file and the item comes before the release of FTN95 7.0 that is documented in the file.

Seems OK to me.

Yes I think you are right in that it can't have anything to do with the problem.

The only mention I can find in he code of anything that looks like %gr, %og or %gw is the following statement:

  I = WINIO@('%pv%^gr[black,user_resize]&',IWIDTH,IHIGHT,RESIZE)

Catherine,

Clutching at straws:

I'm puzzled by your %gr, as with user_resize and the ^ qualifier you need a callback function, and I could see that was the integer function RESIZE, but then where is the user_supplied graphics handle?

Here's the equivalent from one of my programs (predating the RGB colours default)

      IA=WINIO@('%pv%^`gr[white,rgb_colours,user_resize'//
     &          ']'//
     &          '&',IXRES,IYRES,IHDC, GR_callback_FN)

(apologies for the first continuation). Of course, it may simply be the case that you typed it incompletely, or it may be that a graphics handle wasn't required and now it is.

Eddie

I was just about to try a modification in line with that suggesred above. However, before doing this. I re-linked one of my programss and I am back to glorious techniclour! A second program likewise.

I have had no clour for almost 6 months. During that timeI have continued to modify, compile. link and run the codes almost daily. (None of my changes have involved the graphics routines which have been unchanged for many years). This morning things have returned to normal as suddenly as they went wrong. It must be because it is my birthday.

Many Happy Returns, Catherine, but the fact remains that you need an extra parameter to the format code, so maybe it will work, maybe it won't, as it is.

Eddie

Thanks Eddie.

I will amend the line to

I = WINIO@('%pv%^gr[black,rgb_colours,user_resize]&',IWIDTH,IHIGHT,RESIZE)