Support basic configuration defines for the operating system, and compiler, and some basic features (like character set).
Allow use of block-allocation. The main reason to disable it indescriminantly is for debugging purposes (looking for memory leaks). But others may have other reasons.
Defaults to true.
This define allows control over whether we perform a packing optimization to save memory. If we do (qAllowRowsThatAreLongerThan255 FALSE) then we asssert were are never given a row > 255 pixels. Similarly, we disalow rows of more than 255 characters. If qAllowRowsThatAreLongerThan255 - fine - we just don't optimize packing.
For now, not fully implemented. Only for RowHeights, not for RowStarts.
Be sure debug #defines setup properly. These are just some sanity checks. In Led - we use qDebug. Just make sure other defines are setup consistently with that define.
The default value of the qDebug variable is !defined (NDEBUG)
But typically, it is set externally via prefix files (Precomp.pch, MSVC settings dialog, or some such).
qDoubleClickSelectsSpaceAfterWord is a very silly idea, imho, but it is a standard UI feature on MS Windows editors, and not uncommon on the Mac. As far as I can tell, the idea is just to select a word, plus all trailing whitespace on double clicks. The idea is that this somehow makes cut/paste work more easily. So it is sometimes refered to as smart cut and paste or intelligent cut and paste.
By default I USED TO enable this only for windows. Now it is always OFF by default, since I think its too stupid, and annoying. Someday soon I'll implement better smart-cut/paste like Style(on Mac) does.
On slower computers, this can make scrolling appear a bit faster. At some risk to predictablity...
Led contains lots of internal debugging code which is mainly intended to find bugs in Led itself. Its less valuable for finding bugs in your programs' usage of Led. Much of that debugging code makes Led quite slow (for larger documents).
The Led sample applications are all built with qHeavyDebugging when qDebug is on. But Led defaults to having this value false, so that your applications won't be needlessly slow.
If you run into some subtle bug, or if you aren't worried about the speed of Led with large documents when debugging is ON, then you may want to turn this flag ON.
If defined true (which it is by default, unless you've specified
qSupportLed23CompatAPI), then define all Led code in the namespace 'Led'.
This can prevent Led's names from conflicting with the names of variables, and functions etc in other libraries you maybe integrating with. It allows Led to use shorter, more common names, without worries of creating such conflicts (not really taken advantage of as of Led 3.0d6, 2000/04/14, howevever).
It was a difficult choice deciding how to deal with character set issues. There are four major character sets I was immediately concerned with supporting, and, of course, hundreds more that I'd like to be able to support in the future. And then there is the question of supporting different character sets at the same time.
Since my immediate contractual obligations only require support for SJIS, and possibly ASCII, and or Extended ASCII, and not in any mixed form, I've allowed myself the luxury of not worrying beyond that for now. Also - I've taken the approach of building the choice of character set in at the compilation level. This is a simplification since it allows me to make type choices (as WinNT does for UNICODE) depending on character set choices. The difference probably doesn't matter for different single byte character sets.
Anyhow - for the time being, the character set defined at compile time is given by qLed_CharacterSet.
qLed_CharacterSet can be any one of the following:
Depending on which value is specified, Led will automatically define one of:
WARNINGAll this character set support is subject to change, and is being re-thought for future Led releases. I probably will go in the direction of just supporting ASCII, or UNICODE. And not all the various MBYTE character sets (mainly cuz then no good way to mix charactersets within a document). -- LGP 970722
A trick to get better (worse?) interactivity in typing.
Defaults to true.
Do we need to explictly support the IME?
NB: qProvideIMESupport used to be called qRequireIMESupport, but now we simply provide it, and it essentailly becomes a no-op if you've no IME installed.
This is ON by default (for windows). It degrades gracefully if no IME found.
Roughly this corresponds to the MSDEV -DUNICODE -D_UNICODE define. But can be used for other things as well on other platforms? Maybe?
Replaces 'qUsePragmaWarningToSilenceNeedlessBoolConversionWarnings', 'qQuiteAnnoyingDominanceWarnings', 'qQuiteAnnoyingDebugSymbolTruncationWarnings'
A way to incrementally, semi-backward-compatably implement API changes. Also, this serves as documentation.
Any methods etc marked with qSupportLed23CompatAPI will be supported (assuming this flag is set true) for Led 3.0, but probably NOT thereafter. You can get your programs compiling with this set true (default setting). But you should try getting stuff compiling with this set OFF soon thereafter. Using the NEW apis will (hopefully make your code clearer), but at any rate, make it more easy to migrate to the NEXT Led release.
For supporting openening URLs.
Disable activeX when compiling for mwerks CW10 doesn't have it yet - LGP 961013
For URL support, and any other places where it is appropriate, should we try to use Internet Config (IC) when available? Mainly used right now by URL embeddings. Default to TRUE on mac. Not avialable elsewhere.
Use of TmpMemory on the mac allows for the editor to run in a small partition but to use all available system resources (memory) when the user requests it for a large clipbaord operation, or opening a large file, or whatever.
I believe it generally makes sense to leave this on.
LGP - 960314
Led already has very little flicker. This is because we are very careful to draw as little as possible, and to draw quickly. But some cases still exist. Like large pictures being drawn are flicker, cuz we must erase the bounds and then draw the picture.
Using this gets rid of these few cases of flicker, but at a small performance cost in overall draw speed.
THIS FLAG IS NOW OBSOLETE (as of Led 3.0b6). Its still supported for backwards compatability. But now all it does is set the default VALUE for the ImageUsingOffscreenBitmaps property.
Instead of using this, use
When we attempt to draw Macintosh Picture objects, should we try using QuickTime For Windows? If not, the rectangle where the picture should be will be left blank.
For supporting openening URLs, use DDE to an application with Spyglass SDI/DDE. This takes over DDE processing for your app (if you care, this could probably be fixed).
Detaults OFF now (as of Led 3.0d5, 2000/04/03) - because this may fail when Led embedded in OCX, and seems of only very marginal value anyhow. The ActiveX stuff SHOULD work, by now!
For supporting openening URLs.
Win95 doesn't completely support UNICODE. In particular, the clipboard/Drag&Drop stuff does't work with UNICODE. This workaround is on by default, and really only does anything if qWideCharacters is set on (depends on character set you've defined). This is here mostly for documentation of why I'm doing these workarounds (so they can be lifted in the future), and so folks can conidtionally compile them out as Win95 fades into history.
This is ON by default (for windows, and if _UNICODE not defined - cuz there is no point - _UNICODE doesn't work on Win95)