【记录】TJS相关整理

如果这个年头还有人想玩TJS的话，还是可以用VSC来搭一个简单的开发环境
VSC需要一个ms-vscode.cpptools扩展，用来F5启动
setting.json配置
"files.associations": { "*.tjs": "javascript" },
"javascript.validate.enable": false,
"typescript.validate.enable": false,
"javascript.suggest.completeJSDocs": true
将TJS作为JS文件处理，使用一定限度的JS语法高亮补全，以及JSDoc
launch.json配置
"configurations": [
{
"name": "提示名",
"type": "cppvsdbg",
"request": "launch",
"cwd": "${fileDirname}",
"program": "${workspaceFolder}/tvpwin32.exe", // ←替换为krexe的名称
"stopAtEntry": false,
"console": "newExternalWindow",
"args": [
"-param=value" // ←System.getArgument能获取到的参数
]
}
}
然后，随便创建一个tjs文件打开
点击右下角底边栏上的{}，点配置config，自动创建jsconfig文件，然后就不用管了
如果在文件列表看着闹心的话，在setting.json里添加类似配置，忽略指定文件
"files.exclude": {
"**/tvpwin32.exe": true,
"**/jsconfig.json": true,
}

有限使用JSDoc的方法呢....
在Data下创建JSDoc文件夹，创建Main.js，然后先扔着
回到tjs的入口文件，默认是Startup.tjs，填入
function require(){}
require( "./JSDoc/Main" );
这时已经引用成功，按住Ctrl点击路径即可跳转到该文件
再在Main.js下面创建一个Parent的文件夹，在Parent下创建Parent_Main.js
Main.js只负责整体引用，继续填入 require( "./Parent/Parent_Main" );
这个Parent文件夹，用于存放父类，也就是TJS2Doc和KRZDoc相关的JSDoc文档
但需要注意的是，由于有一些东西与JS默认的文档冲突，所以需要统一改名，这个除了父类文档以外就没这破事，我这里的做法是前置加T_
一个文档夹，或者一个模块，由三部分组成
Modle_Main.js 用于引用其他的文档
Modle_Class.js 类文档
Modle_Const.js 全局变量文档
在Modle_Main.js中，先引用全部的类文档，后引用全局变量和可能存在的全局函数文档
因此，Modle_Main.js，在上面实例上是Parent_Main.js
举例我现在要写一个System类的文档，改名后叫它T_System，所以Main现在有以下代码
require( "./T_System" );
require( "./Parent_Const" );
创建T_System.js文件，写 class _System{} 文档
在Parent_Const.js中写 const T_System = new _System();
这样就可以在tjs侧直接使用T_System和相关的文档补全，但要注意在TJS侧声明对应的值
另外，如果是自定义的类文档，可能需要在JSDoc中反向引用回定义文档
这个时候用require的话会导致文档失效，使用import()可解决这个问题，同样单击import内的路径可跳转到对应文件
而自定义类的tjs文件，可在引用Main.js后，再列一条对应文档的引用




此时在能识别JS语法的时候，JSDoc可以正常工作，但也一大堆毛病
比如with不支持，文档独立出来是因为class内的function之类的识别问题，等等
有很多地方JSDoc不见得能捕捉到你的变量类型，所以...............
JSDoc的写法自行百度，推荐一个插件mutsuntsai.jsdoc-link，能处理link标签
至于为什么不放一份父类文档上来....因为我实在没那个耐心把它写完

玩TJS所需的东西基本跟TJS没啥关系，除了处理KR的坑以外，更多是设计模式
例如从巨型类复杂继承，转到组件化，这个东西跟TJS本身就没啥关系
所以如果要好好玩TJS的话，我还是建议正常的程序入门.....但确实就不如直接U了
TJS最基础也是最经典的坑，是继承的是访问路径的那个字符串，而不是类型
class a extends b{} 它实际上是这样的，它用Scripts.eval执行了每一段extends的字符串
所以extends b，实际上是extends Scriptes.eval(b)，返回的是global.b
同样的，你也可以定义一个函数返回一个类，比如下面这段定义一个函数d，然后extends d()
这东西简直折磨，类内类之类的玩应基本没得用，因为它eval的上下文是global........
同样的，在多重继承调用某个类的构造函数的时候，也要这么.过去......

TJS的析构函数，在析构函数调用类成员它会告诉你未定义，似乎析构之前已经清理干净了
那我要这个析构干嘛.......
TJS是没什么像样的类型系统的.....类型系统这玩应只能自己造
但，Scripts.getClassNames，对class无效，必须要实例化
就更不用说其他乱七八糟的东西了，比如instanceof的右值只接受字符串
(Dictionary.func incontextof target)( parameter );
我相信一开始看到这玩应都会懵逼的，但字典确实只能这么用....
var a = 1;
class b{ function b(){ System.inform( System.eval( "a" ) ); } }
你会惊奇的发现它不会报错，还会一层层查找上去- -

tjs的执行没有多线程，看起来的异步，也是把消息压到消息泵顺序执行
tjs有一些魔法.....比如 incontextof 可以切换上下文
function a(){ inform( title ); }
System.check = a incontextof System;
System.check();
exec，execStorage，都可以通过return返回一个值
所以可以做到文件里返回一个匿名函数，在写Config或者脚本片的时候这个魔法很好用
另外，z的eval，exec系列函数，都可以指定上下文，虽然不太建议用
kr的资源管理...z亏了是有个Bitmap，但Sound和Video都没有对应的Buffer类
这些东西也不是天生带的自动加载，kag那种自动补全后缀，是要自己写的
自动路径有利有弊吧，毕竟不能用./和../路径..........
Timer和Trigger，在Window创建出来之前，触发间隔为60ms+，窗口创建后正常
大概是创建窗口之后把对应的实现切到了窗口的消息循环上吧......
windowEx.dll需要menu.dll作为前置，不然可能没有被依赖的Menu类........
一部分组件，因为一定要窗口才能初始化，还原简直不要太费劲
同样也因为这一堆需要窗口创建的东西，把一部分结构和流程搞得乱七八糟......
Layer这个巨型类放到现在可能还是分开好点，而且Layer和Layer的概念也不一样......
正常来讲Layer这个位置应当是只有数据Buffer，添加到Canvas监控绘制的，但kr没这个结构
虽然Z的文档里有一个BitmapLayerTreeOwner，但这东西在内核里是空的
看得出来就是个Canvas的雏形，但它是空的
TVP渲染不支持浮点数，浮点会直接被abs掉........且CPU渲染效率低的有点
Trans和Video，如果直接这么用还好，但如果要抽帧的话，折磨......
使用脚本片返回一个对象，设置被操作的绘制主体
使用属性调用绘制方法操作绘制主体，能让复杂的图像操作得以保存，但需要结构化
KR是左上角坐标系，一旦对图像进行旋转，就有可能出现图像大了，不显示的问题.........

tjs对对象的引用计数和释放是在内部自动的，虽然可以用 invalidate 把对象直接无效化调用析构，但就像上面说的，那个析构...................
所以如果想要类型系统和一些相关操作，构造和析构这一套东西都要自己重新造..........
class未被实例化的时候，也可以调用函数，相当于静态函数......
但这个时候class内的值都没被实例化，所以可以写一些不用值的函数
有些32的dll，在后续的64版本没有对应的dll.........
kr的窗口是可以做无边框的，但做不了异型窗口
我反对没有真正需要的子窗口，但选择类的东西又没有对应的Win32API可以调，何必呢...
但用drilist倒是可以打印出内部的目录结构，但这玩应也用不着子窗口啊- -用kr写editor嘛

好详细谢谢