Vanishing Values

[Scott24x7]

I have experienced a very unusual behavior... I made a slight change to philosophy in enabling fields. Essentially I wanted to show disabled fields that are never editable in an italic font. So I changed my textbox by adding a "lForceDisable" property to it, and then in the refresh, I set:

IF This.lforcedisable = .T.
	This.Enabled = .F.
	This.FontItalic = .T.
ELSE
	This.Enabled = ThisForm.Editing
ENDIF

So I thought it might be something programmatic, but when I changed one of the fields to physically set ENABLED = .F., while FontItalic = .T. it still would not display the INT value. When I set FontBold = .F. and force the field disabled, then it displays fine...

What is it about FontItalic and integer values? Has anyone else experienced this issue?


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

I just set a textbox to fontitealic=.T. and enabled=.f. and it looks the way it should. Also with an int in it.
Are you using a font without italic digits, perhaps?

Bye, Olaf.

 

[Scott24x7]

Let me try to change it. The font I use is MS San Serif.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

Oh, even before I test it, that doesn't sound right, because all other fields with non-int values it works fine... it's only with integer values.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

Hi again.
Well, a font change does work, but I'm unclear why. The font I was using is MS San Serif, but there is another version which has an A preceding it, and also "MS San Serif". When I use that one, the values appear. But what is still very odd, is that the values appear for other fields with the same setting with Date, DateTime and Text (char) values. It is very unusual that Int values don't appear, but that is the only data type that is affected.
I guess I will have to go back to base classes and change all the fonts to this one, as even though it has a "same name", it's appearance is still significantly different to the one I was using. I guess another lesson learned...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

I think you talk about the A icon. Seems it indicates ttf (true type) fonts.

I can reproduce what you see (on Win7), so it's not about the digits in the font. Actually from what you said I thought the digits would appear, only not be rendered italic. My fault.

Dates display indeed, and of course they also contain digits. Date automatically left align and setting an integer textbox to left align, the number appears. Seems to be an alignment problem, more general a GDI+ problem of rendering text as graphical output. Automatic alignment means right alignemnt in case of numbers and that may put the text too much to the right, out of sight. A bug in size calculations of the text graphic, most probably, if the text width is computed narrower than the gdi graphic is, it's put too much to the right.

We might find the more general bug rule, so far everything indicates non ttf fonts are buggy with automatic or right aligment at least. Further investigation would pinpoint the real reason perhaps.
Anyway using TTF fonts is recommendable anyway, as these are best supported with all features around font rendering, including anti-aliasing (smoothing) their edges.

Bye, Olaf.

 

[Mike Lewis]

I've come to this thread late, and haven't tried to reproduce the problem. But I wonder if it might simply be a case of the control not being wide enough. With many typefaces, the italic version takes up slightly more width than the roman. That might be what's happening here.

But this is just a guess. Feel free to ignore it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, a value of eg 100 could be displayed about 5 times in a standard width textbox. The bug is more enormous than the few pixels. Simply try a textbox with the non ttf font MS Sans Serif and you'll see the effect. If you move the cursor to the right end of the textbox (eg via the "End" key) you'll see the italic number. It's narrow enough to not be put hat far off, though.

Bye Olaf.

 

[Scott24x7]

I can see I am once again haunted by the past...
I remember an avoidance of "special fonts" (i.e. non-system fonts) in the past because moving an application often meant the font wasn't available in another machine. So there was (at least at that time) an avoidance to using TT and other fonts that come and go. It's interesting that it didn't bite me before now, b ut I was trying to manipulate the field a little differently from what I normally do.

So, I can see it is time to embrace the modern and make the change. That's what led here to start with actually (same with my previous issue about getting rid of tab borders). Looking to make my look & feel in more modern styles and it's led to a lot of changes, and breaking things that worked for literally decades. I don't mind... it takes about a day to get everything in order, and then move on with a nice modern look and feel, and then don't have to worry so much about it as more functionality goes into the system. I've almost finished my first round of "core" functionality. (In the end there will be 5 "core" modules, depending on what is needed). But this first one is the most urgent. So that's where my focus has been. When you get to the point of starting to "pretty up the interface" you know you're getting close to having the core ready. So that's a good feeling.

I want to have most of that ready to take advantage of the time as SW Fox as well. So I keep working 15 - 20 hours a day on this for now. Thanks for the advice, at least I know the issue now and can work around/avoid it going forward.
And, my interface looks better now as a result anyway.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

If there was a time TT fonts were bad I assume that was in DOS times, maybe early Windows versions, too. The paradigm has inverted, today TT fonts are best supported by Windows and VFP. Never ever go back to Foxfont, it'll not work out good.

Bye, Olaf.

 

[Scott24x7]

Olaf,
Yeah, this is going back to Late Win 3.11 early Win95 and the FPW2.6 for Windows to early VFP3. There is still code in my core that dates back to FPD2.0 days, with some modernizations. That's not all bad, as there are things that have 10,000's of hours of use on them, so I know they are reliable. But I have this weird mix of "old and new" right as I was "fading " out of development before. So jumping back in now, is like trying to interpret US tax code... what was ok one year is out the next.
But thanks for this. It does look much better, and I don't see it being an issue as you mention now. So I'm putting in the effort to revamp my base class library, and get everything aligned, update the forms after the class changes (some formatting is required). But it looks much better, so I see the value in doing it this way.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."