I think I've run out of ideas on this one, so I'm hoping someone else has seen this problem.

 

 

The display is for a nav system, but it appears that the IMAGE_USE_ERASE flag is just not being applied when the leftside string updates. The string display code for both sides is identical (except for things you'd expect, like co-ordinates!):

 

 

- and so is the update code:

//---------------------------------------------------------------------------
FLOAT64 FSAPI	ins1_lat_string_cb(PELEMENT_STRING pelement)
{
ins1_LatitudeDisplay();
sprintf(pelement->string, "%s", ins1_lat);
REDRAW_IMAGE(pelement);
return 0;
}
//---------------------------------------------------------------------------
FLOAT64 FSAPI	ins1_lon_string_cb(PELEMENT_STRING pelement)
{
ins1_LongitudeDisplay();
sprintf(pelement->string, "%s", ins1_lon);
REDRAW_IMAGE(pelement);
return 0;
}

Debugging shows that the string data is being passed in correctly to both displays (five or six characters plus end-of-buffer). I have tried forcing the erase flag in the ins1_lat_string_cb callback but that had no effect. I have also copied the entire gauge to Notepad to ensure that nothing should be in there that's above ASCII 128 and copied it back as a new .c file. I use 'Rebuild' rather than 'Build' and my build commands have 'Incremental Build' turned off so that everything is redone from scratch each time.

 

I'm beat!

 

-Dai

What happens if you reverse the order of drawing? Does the problem migrate to the right display? I don't see anything at all wrong myself... :Thinking:

Are you manipulating the strings 'lighting'?

Ed: No. Both sides are set to IMAGE_USE_BRIGHT only.

Bill: I'll try that and get back to you.

 

-Dai

Dai, just a couple of questions:

 

1) Why are you using a string format "%s" instead of a float like "%f5.1" ?

 

2) I notice you are defining 5 chars for the left display, with a display area of 185,60; that would handle an integer of 5 digit; what happens if you add a fractional point? the string should expand a little, so it woudn't fit exactly the same? I see the fractional number in the left is a bit compressed and doesn't fit exactly with the integer value that is behind (or maybe I see wrong?) Maybe this is part of the problem?

 

Tom

Bill: Swapping sides didn't swap the problem

 

Tom: It is a pure string. The 'decimal point' is a separate display, giving the appearance of a float. Both displays can show eight different sets of information depending on the display selector, so I chose to convert all data to strings before passing it to the callbacks for display.

 

I also eliminated the 'ghost' background string just in case it was having a bearing (ouch! bad pun) on the problem but that also made no difference.

 

I think that the swapping sides test points pretty well to a display problem rather than a data problem. I'd also go so far as to say it seems to be showing something we've always believed impossible, in that as the string starts updating it's moving a couple of pixels to the left of its original placement. Yes, I have tried drawing it somewhere else, but again to no effect.

 

Back to throwing darts in the dark....

 

-Dai

Have you tried removing the REDRAW_IMAGE() macro from the callback function? I don't think is necessary.

 

Doug

Tom: It is a pure string. The 'decimal point' is a separate display, giving the appearance of a float. Both displays can show eight different sets of information depending on the display selector, so I chose to convert all data to strings before passing it to the callbacks for display.

 

Yeah, I know about those displays as time ago I programmed a CIVA INS completely in XML. After some evaluating tests, I decided to use bitmaps for the digits as string text gave me trouble with the appeareance when resizing/escalating the background panel (something different of your case, just anecdotic)

 

Tom

Off topic, but because of the quarz font in the INS.

I forgot and cannot find it.

Is there and attribute in formattedtext to make the font italic, like uc for upper case?

 

edit, found it.

Have you tried removing the REDRAW_IMAGE() macro from the callback function? I don't think is necessary.

 

Bugger but that was it Doug!!! I originally needed it there because I was manipulating the string colour and as the problem was only affecting one side, I thought nothing of it. Putting a lot of small details and tests together, it seems that any drawing macro can fail to work correctly if it is asked to update too frequently - not just string manipulation but icons etc. too. I think the reason the other side was not failing is because the data was updating much more slowly, thus allowing the REDRAW_IMAGE() macro to complete before being asked to run again.

 

Another detail for sd2gau...

 

-A very relieved Dai