TB Gold wont set certain fonts

CALL TC_Win_SetFont(0,fontname$,size,"style") under TB Gold 5.5b19 will not set certain fonts, whereas the code runs perfectly under TB Silver 5.33. Both are calling the same LIBRARY set. One of the fonts which will not set is "Aloisen New" which is a music note symbol font.

There are a number of problems I've run into so far. This is the one holding me up right now so let's start with this one. Does anyone know how to fix this?

Thanks.
Regards
M. Canaday

Comments

Font Problem

Hi Big John,
Thanks for the info. I haven't tried it yet, but I guess this means that binding any program under 5.5b19 will inherit all its bugs, even if the code ran correctly under Silver 5.33? Sorta defeats one of the main purposes for buying the new "dll-less" version.
I don't quite understand what's going on with True Basic. Obviously, someone had to program 5.5b19; as the code is obviously different from that in 5.33. Now that a bug has been found, what you are telling me seems to be that no one now knows HOW to correct it...? Or just WON'T correct it? Is one now expected to PAY for the next version in order to get something that works? If so, that would imply that someone IS there to program a "next" version.
So far, all I have heard of is that you (not TB, Inc.) are doing all the work that's getting done (i.e., a new editor, and those great modules on your own web site), but that doesn't include doing anything with TB itself because, incredibly, no one has the source code???
Does this mean that all version 6.6 is, is the same old thing with the same old bugs, but with just the new editor? I hate to rant about things, but this software is pretty expensive to be so fouled up as it apparently is.
Thanks again Big John for your answer to my font question.

Regards, M. C. Canaday

Fixes

Hi Mike,

First, thank you for the work you do getting to the bottom of bugs in the software. Without users like you reporting them, we couldn't work to fix them - which is a priority more now than it has been in the past.

Second, rest assured that we're doing everything we can to permanently resolve the persistent issues with the core language. Resolving bugs that have been present in the language for years is not an overnight job. While we're working on this, John is building elements into the v6 editor to address the bugs as they arise - more fixes than have been implemented for the last decade or so.

So there is a lot of development work on our plate on an ongoing basis. One of the largest issues right now is updating the language to be compatible and functional with 64-bit operating systems - a sea change in computing that we're doing everything we can to adapt to.

True BASIC is now in its 28th year (BASIC itself now being 47 years old) and still vital because its value is real: after nearly 3 decades it remains the only language with this combination of simplicity and power in existence. Middle school kids and highest-level engineers, scientists, and mathematicians use it every day. Few if any other languages can say that. We deeply appreciate your participation and patience while we work to keep it growing, evolving, and relevant. We couldn't do it without you.

reply to comment

Thanks for the "pep talk", but it doesn't help with my font problem. I guess that's not going to get fixed in the near future. No one has access to the source code, right? Amazing.

Anyway, I first used Dartmouth Basic on a C-E-I-R teletype machine in 1967. Still have the manual dated 1965. Later used HP basic on a HP 9830 and 9845. The DOS version of TB worked great. Never saw a bug in it. So I like TB mainly because I've used it for so long, and it's far more intelligible than the other "gobbledy-gook" languages.

But frankly Gold 5.5b19 is fouled up compared to Silver 5.33. The TRC libraries sent with 5.5b19, for the most part, were the same as, and just as old as, the ones that came with 5.33. Some even go back before that. So how are the bugs getting in? What changed so that TB now won't recognize certain fonts? One day when time permits I will find out just which fonts are not recognized. Meanwhile I find it an extremely annoying bug.

Regards,
Mike C.

TBsystem bugs

Hi Mike,

The earlier releases of TB version 5 used a third party interface called XVT, and this is why the DLL files were required. In version 5.5b19 WINDOWS APIs were adressed directly instead of using the XVT interface, so no DLL files were required. This is where the new bugs crept in. In other words the code that replaced XVT did not replicate XVT exactly. The core language has always remained the same.

Regards
John

TBsystem bugs

Hi John,

Well, thanks for this info. One of the things which apparently got changed is how the fonts are "looked at", or whatever goes on inside.
The line:
CALL TC_FontsAvailable(fonts$()) results in listing 127 fonts under Silver 5.33 and 32 under Gold 5.5b19, on the same W7/64bit computer, which actually has 244 fonts installed. So by some reasoning a large number of these fonts are not considered worthy of mention by the two TB versions. As I understand it, this must be due to the XVT and API situation you mentioned above.

I have not had time to sort through to try to determine the rationale involved in not reporting all fonts on the machine. It probably has to do with one of the assorted attributes shown in the W7 Fonts folder, in which a lot of the columns are left blank.

But one of the fonts of immediate interest to me is not reported as being available by either 5.33 or 5.5, yet the call to TC_WIN_SetFont will set that font in 5.33 but not in 5.5. The same result when bound into EXE's. So that also must have to do with the dll's, if the core code is as it has always been. Maybe one day I will write something to see what fonts will set and what won't set.

Again, tanks for your reply.

Regards,
Mike C.

unrecognized fonts

Another factor that _might_ be in play here--certainly pops up elsewhere--is that there are still some DOS related limitations built into the language (array sizes, compiled code length, etc.). This is why there really is a need to update the main language module but I suspect that is not going to happen anytime soon--if at all. However, if TrueBasic _really_ wants to stay in the market for scientists and engineers (as stated in another post by admin) things like the 64K limit on the compiled code needs to be addressed. [Yes you can break large programs apart into modules, but that becomes a major pain!]

This font problem is, as stated, most likely related to the XVT, API, dll transition with 5.5x, but how these interact with the very old language code is well beyond my expertise.

:-(

rwt

Font Problem

Hi Mike,

If your font setting code runs with version 5.33 but doesn't run with version 5.5b19 then this points to a bug in version 5.5b19.

For the moment, I don't see an immediate solution. One solution is to fix the bug in version 5.5b19, but I think this may never happen. The other alternative is to try to fix the TBsystem file for version 5.5b19. This too is not going to be easy.

Regards
Big John

5.5x versus 5.3x core files

John et. al.,

This may be off base, but it seems to me that the biggest change in the newer language module was the loss of the .dll files (which kept changing through the older versions). I assume Chris incorporated these library files into the language modules themselves so that WE, as users, didn't have to include those .dll files with our software (something I praise highly). It would seem to me then, that discrepencies between older TB versions and newer ones, like this font recognition problem, may have a core cause in those libraries and how they were transferred into the newer versions. It is also suggestive that those .dll libraries as they were updated through the progression of TrueBasic versions, might contain some code that keeps TB somewhat current with WINDOWS. As we have progressed through 3 versions of WINDOWS since the last major language update (Version 6 is really just the new editor not a new language version) then a place to start looking may be with what is actually in the .dll files from the older versions and how did 5.5x do away with these. [I would guess that a clue to this is why those .dll files kept changing through TB versions.]

This font problem and the HP printer problem both reek of problems of communications between TrueBasic and WINDOWS.

While Big John's editor can use 5.33 as the language module there are two important limitations to distributing software written under 5.33. One is the necessity of including these .dll files. One could live with this. The other factor is, in my opinion, more serious. The 128 character pathname limitation in these older versions just doesn't work in the modern environment. For example, I distribute a LOT of software around the world. My packages unzip with two or three levels of folders and the user may well want to store the software in a folder that is two or three levels deep. It is then very common in current usage to use a desktop shortcut to access such programs. It is really not difficult at all to exceed 128 characters in the complete path of a desktop shortcut. So--for some of us, 5.33 is just NO GOOD anymore. (There are also some newer pixel routines added to the 5.5 language that I use extensively).

My $.02!

rwt