Now taking requests for version 7

The headline says it all: I'm pleased to announce that we're officially in the planning stage for developing a fully updated version of True BASIC, with a tentative release date of late 2014/early 2015.

The immediate plan is to address known bugs in the system file, make some structural refinements to add better support for audio and video files, USB ports, etc., but this version will also include a long-awaited Mac OSX release. Our second-stage plans include Linux and mobile platforms; cloud coding and compiling is also on the wish list.

Documentation updates are also in the works, as well as versions for e-readers such as Kindle, feature-rich PDF, and (possibly) a return to print for the user's guides. This is also in the planning stages at this time.

As part of our planning, we're actively soliciting feature requests and suggestions from the user community. You're welcome to post those here or email us at support@truebasic.com. Let us know what you want to see in TB 7.

To help defray the substantial costs involved with this project, we will likely be launching a Kickstarter campaign in the coming weeks - stay tuned for more details and information on how you can get involved and earn rewards like upgrade discounts and free licenses.

Comments

mouse wheel

I'd ALSO really like to be able to scroll text in the editor window using the scroll wheel available on most current mice!

mouse wheel

I second that!

A silent installer would be

A silent installer would be great for pushing out updates and installations via SCCM. Just having a "/s" option in the setup that chooses all default installation settings would be nice, having other command options would be even better.

Feature request: Unicode support

Support for Unicode would be nice, but probably a pipe dream, eh?

Regards ,
MCC

True Basic 7 desired feature: A persistent output window

A persistent output window aids development by allowing you to study your results.

It was persistent in TB2. And, if no graphics were used, it was scrollable and copyable (limited by buffer size). The open-source Decimal Basic can do this, plus save the window contents.

(Also, TB2's command window is much more user friendly than TB6's disappearing commands, if you can bring that back. Though as long as LOAD and SCRIPT work I can live without the window.)

Previously I asked for vector graphics, which would be nice but is probably more difficult, so this is my priority. Since my graphics requirements are mostly graphs, I use the workaround of using True Basic code to generate Gnuplot scripts. Gnuplot is free and can create a wide selection of graphics formats (and graph types), so it meets my production needs.

I would be delighted to help test True Basic 7 for Mac OS X, if you'd like the help.

Windows Registry

Adding a library to read and write to the registry would be great. Using INI files are old school. I don't know about the Mac but I'm guessing they have something similar to a registry. It's important for my programs to remember previous settings and values.

Time frame

Is there any time frame for this. Considering how long the bugs in the present version have been there unattended is any of this going to become reality. I like True Basic and would like to see it advance but the forum activity is all but nothing, I do not know how this reflects on sales and revenue for product development. It is unfortunate but there are now a lot of free versions of Basic available, also a lot of products that are paid for which are much cheaper than True Basic that are cross platform already so competition is steep.
A road map for development would be appreciated.

Regards
Dave

Vector graphics for True Basic 7

A Mac OS X version -- be still my heart!

OS X support is plenty, but as an additional suggestion, it would be nice to have some way to save TB drawing commands in vector graphic files. TB 2 for Mac could do this by journaling the PICT commands into a PICT file, which allowed using the TB-generated graphics in almost any Mac application.

As an example, my TB 2 programs generate ~4 kB PICT files for reports; from TB 5, these are ~3 MB bitmaps, and they're of course pixelated. (Resaving them as PNGs shrinks them to ~30 kB but doesn't cure the pixelation.)

So some way to record the PDF (OS X's native graphics format) to a file would be great. It could also be EMF for the Windows version, which is native there. Or SVG, a PDF-like up-and-coming web vector graphic standard. But really, just running in OS X would be an answer to my prayers.

TB graphics for windows

If I knew how vector graphics worked then I suspect that the quickest way to do vector graphics in Windows would be to use a library module. The current internal file format for Windows images used by TB is a complicated bitmap format based on r,g,b color values for each pixel, hence the large file size. A library module already exists called pwlib that allows the user to draw graphics on screen using PLOT statements where the pixel size is governed by the size of the paper sheet that the graphics are printed on. Small type faces as small as 1mm high letters can be printed (and you can read it too with a magnifying glass). In principle it should be possible to use a short hand notation instead of PLOT x1,y1:x2,y2 to produce a compressed vector set of instructions in a small file. All that is required is a library routine to reconstruct these vector definitions back into PLOT instructions. This is what libraries are good at.

TB vector graphics

As I understand it, journaling vector graphics for classic Mac OS (pre-OS X) involved a system call to start and stop recording the QuickDraw PICT instructions True Basic itself generated; this resulted in a PICT file (or resource). Most any Mac program could display this with another simple system call, which was executed by the system QuickDraw routines. This feature disappeared in the transition from TB 2 to TB 5.

TB Gold 5.5 and later also includes a library which translates the TB graphics statements into PostScript on-the-fly and saves them in a PostScript (text) file, which can easily be translated into a PDF file, the native graphics format of OS X. Unfortunately, the translation to PostScript has errors, among which are that MAT PLOT does nothing and all text is 12-point Courier rather than the requested font, face, and size.

It might be possible to modify that TB PostScript library to record SVG, which uses the same drawing model as PostScript/PDF, is a W3C standard, and can be imported and edited by numerous drawing applications -- which could then export native graphics on their host platform. More steps, but bearable.

A capability of the same sort exists in the open-source Gnuplot (gnuplot.info), in which output formats are called "terminals," since they will display on screen or write graphics files. A TB library that generated the input format for the terminal modules could also display in multiple formats. As I mentioned above (7 Jan 2015), my True Basic programs now write Gnuplot script files which are then used to create graphs in my desired formats.

As I also mentioned, I would prioritize a persistent output window before vector graphics.

Journaling vector graphics

A Mac OS X version -- be still my heart!

True Basic 2 for Mac could record and save vector graphic files (as PICTs) as they were drawn. I'd love to see that again, as (current Mac native graphic format) PDF, or SVG or whatever, as long as it's vector. It could also be EMF on the Windows version.

CHAIN command update

This post mostly is to test that the forum is working since there have been no posts since the switch in web service provider (which has remarkably speeded up access on the site) and to see if the time stamping updates.

I think this has been documented elsewhere in the forums, but the fact that no spaces can appear in the path name in the CHAIN command is extremely limiting on modern systems. This is probably one of those DOS hangovers where spaces weren't allowed (I still tend to connect multiple word folder names with connecting underline characters) but on today's systems, the path to almost any folder is likely to have spaces. So this one certainly should be on the list.

rwt

TrueBASIC 7 Feature Request

I'd like to see more compatibility with the ISO standard; That would be things such as an indexed file type and the entire real-time module.

CONTROL OF SCREEN RESOLUTION

While the current True Basic can detect a computer's current screen resolution and one can create a window to fit or match, there are applications where one would like to control the computer's resolution. I know of several 'reasonably' simple games that change the screen resolution to execute and then change it back when closed. Other games offer a choice of resolutions and change it as a 'preference' then change back on exit. This would be a nice control to have within a True Basic program.

rwt

re: requests

I think we've covered most of the major requests in the cited previous thread. I guess I would prioritize as:
1) upgrade limitations left over from the DOS versions: program size, array limits, path length limits, etc.
2) reliable printer support from within programs (the current editor utility does no good when running programs.)
3) as mentioned, some updated sound support--a built in player for at least some current sound files with the option to continue running code once the sound file is started. Same for video although chaining out to a player has been possible for a long time now.
4) maybe extend read_image to include other file types
5) an extended palette beyond 256 colors. Yes there are now ways to access unlimited colors but it would be nice to have more tan 256 permanently assigned colors. Perhaps returning to a Set Color Mode command to setup 256 and maybe 1024 color palettes.
6) Having abandoned MAC support after Apple broke system 9 programs, I don't know how system 10 treats things, but one of the frustrations with earlier Mac programming was the fact that Apple switched background colors for doing animation masks. It would be nice (if needed) to have True Basic automatically switch color numbers on the Mac for black and white so that porting between Windows and Mac would be more transparent (in other words NOT require different graphics with backgrounds switched from black to white). I'm assuming that in switching to INTEL processors, system X may not suffer from some of the animation bottle-necks (at least animation with True Basic) that existed with earlier Mac versions. [One of these used to be that the whole color palette was stored with any graphics image.] Anyway, the point here is to coordinate the Windows and Mac versions as much as possible to make porting between the two as easy as possible.
7) Even for Windows and Mac programs to have touch-screen controls.
8) I certainly would like a way to keep True Basic windows ON TOP OF the taskbar--maybe an option in the TC_WIN_CREATE command. I'd like to be able to use full-screen windows that won't trigger the taskbar if the mouse pointer is moved towards the bottom.

This is a 'start'.

Version 7

The core of the problem lies in the TBsystem file, which I believe is written in C++, not that this in itself is a problem. I know nothing about the way the TBsystem file is constructed, other than the old XVT interface has now been incorporated into the TBsystem file (no extra DLL files are needed for version 5.5xxx). None of the suggestions for version 7 can be accomplished through the editor. The TBsysstem file is the one that needs to be modified, improved, updated or whatever. Most of the current problems with the editor arise from bugs or limitations in the current TBsystem file, such as printing to HP printers. Even running TRU programs has to be done indirectly. Likewise stopping a program from running has to be done indirectly. If we want to run programs on the MAC, then we will need to have two TBsystem files, one for Windows and one for the MAC. It might even be better to have just one TBsystem file with special interfaces for Windows, Mac or smart phones or whatever (as long as it doesn't involve DLL files). If I knew how to do it then I would have started years ago before attempting to write the editor.

Version & for Mac

The TBsystem file is an application, so it definitely has to be different for Windows (.exe) and Mac (.app) even though they run the same CPU instruction sets. Their respective APIs differ significantly for displaying output, reading the keyboard and mouse, and accessing files. But the interpreter can (and probably should) be identical i86 or x86_64 code (tablets and smartphones use other instruction sets and processors -- which are currently more powerful than a 1985 Cray 2 supercomputer). Cross-platform programming has its challenges, of course, but this modularization should help.

The TBsystem file will have to be rebuilt, as all applications must be if they're modified. This is feasible with the source code when the design is known, but otherwise? Perhaps the Decimal Basic project could offer some hints, as they have both Windows and Mac versions. (The language is very close to True Basic, but the interpreter is written in Pascal and uses the Lazarus RAD for cross-platform implementation -- maybe not so much help.)

Better window control,

Better window control, hopefuly this would have been on the bugs list. Fow windows operating systems, access to the windows API. Not sure how that will fit in with the cross platform ideas.

And my biggest annoyances, the high cpu ussage when using truectrls needs to be fixed.

Look forward to the new release.
Dave