From readme.txt
Version 9.9 active-X
1. Remove of a hard finding bug, which in some OS leave tmp files in %temp% folder. The bug was an abnormal initialization of multimedia player. This bug cause the system to hold the tmp file until the player end. This problem not happen in Windows 8, perhaps is a bug of the external lib, for specific OS.
2. Reorganize the M2000 MessageBoxet, so now we don't get any crash at save.
3. Commands LOAD, SAVE and END check a "dirty" flag to ask for saving. Also REMOVE (with no arguments) now ask before remove the last module/function.
4. Speed improved on calculations (expression evaluation).
5. List of COM object's members, return the type of parameters, and if they are IN, OUT, IN OUT, also the return type if the member return value.
6. New objects., SOCKET, DOWNLOAD, CLIENT for use TCP/IP. Info.gsb have the Down3, a module example to show how to download asynchronous three files, using the DOWNLOAD object.
7. (This break compatibility with previous versions). Com Events in previous versions internal passed by reference. So all variables in event service function have & before. Now only for those parameters which are ByRef we need to use &. Before we use an event we can just show the stack, and leave it as is, using the Stack statement without parameters. So we can see if we have values or references, because references in M2000 are strings -they are weak references-with name, and for events they have EV at the begin).
8. New info.gsb. Best of all is the chess game (without AI) but import and export FEN strings, and we can play chess with a friend. Also we can replay the game, or move to any previous move. Also there is a Snake board game, only an automatic version (4 players played by computer).
From info.gsb, the down3 module
The example show a running module. This module create a Form, three Download objects, with events, in an array. For this example we create a two item array, and increase by one. From internal side there are two arrays, the second one has the sink objects, the objects for events. We have a thread to display an increasing value. We can move the form, without blocking the refreshing of the form.
About the items in the picture bellow
The magenta colored form, is the M2000 console. M2000 Environment redirect all graphic and text output base on a layer. Console form has 35 layers. The Back, the Layer, and Layer 1 to 32. Here we see the Back or Background with black color behind then Layer, in magenta. The Background is a Vb6 form naked from borders and headers. The Layer is a picturebox vb6 control, the same for 32 layers above (used as "hardware" sprites, or for pages). The 35 layer is the printer page, or Printer layer. Eanch user Form, is a Vb6 form with an array of gList4 controls. The orange header is a glist4 control. All controls like DropBox, or EditBox actually have a glist4 control. under the hood.
Vb6 (the programming language used for written M2000 interpreter and environment) not allow to place controls in a form, except for expanding a arrays of controls. But a control, from an array can send events to another object, if that object has from design time defined with that capability, for any control with the same type. So a EditBox can place a real Glist4 control, as the "any control" and handle the events and the control.triggered by a task manager. The task manager triggered from a timer from Kernel. But because we have the interpreter in one thread actually we have a switched execution. So where the switch happen/ We have to give time to system for timer to work. When we place a refresh for a form, we do this, we stop the triggering for task manager, then we perfrom the refresh, then we start the triggering, so we place the threads when we want, not every time.
When we move the user form (handling the orange header), we see the thread to slow down (the scrolling numbers), but continue to work. So the form has another "thread layer". Because interpreter execute in console form, and events from user form "travel" to code in console form, we have a switch, where the interpreter main code stop and a service event function executed, and then the main code continue. Here for the example we don't have any event service function for the form. The form is not opened as modal. When an event occur in form, internal code watch if the event serviced, and if not, excluded from firing. If the form lost the focus and then get the focus, at the activation time, the event black list, erased, and fast constructed again.
So in the picture below we have a trigger from Kenrel, events from two forms, the console form which are served internal, and user forms where events are for M2000 code, and we have three objects which download files from internet to a directory, sending "com" events.
I found
here the cAsyncSocket (which a watch for some time), written in Visual Basic 6 by Vladimir Vissoultchev, plus some other classes which use jthat object So the cAsynSocket handle a ws2_32.dll the interface (in binary) for Windows Sockets. Here we have a dll which send events, not by using sink objects (like com objects), but in the message loop. What is message loop? Each program which have forms have one message loop, at least. So for using window socket we need to attach it to message loop. So every cAsyncSocket make a new window, (hidden) get events from Window Sockets, watching the message loop, and generate com objects. The Download object, isn't a ecAsyncSocket, but use one, so events from DownLoad are specific for Download, and generated inside Download. So when we see the number of bytes to increased, we get a progress event from Download, where some other events come from cAsyncSocket, where some specific messages "notify" it from Window Socket system. So behind the Download we have a system in some other thread (actual thread), which get or send bytes over internet. form and to "clients". So cAsyncSocket is a client. We get the events from Download because we have made the sink object at execution time. All the other parts are connected through design time programming. The only thing to think is how the cAsyncSocket watch the message loop. This can be done by sub-classing. Here the sub-classing is different. Not as the subclassing with EditBox and a glist4 control. For cAsyncSocket the subclassing mean to insert a function between a function call. So when A call B we can pass a C in a way to perform a cal from A to C and then from C to B. So we inform the A caller to call C and we get the information that A actual want to call B, so we get the B address to call, before setting the A caller to call C. Before we close the thing, we have to restore the sub-classing. This is the idea. If something in C not work fast, then slow down the message loop. For M2000 interpreter there is a programming "switch" who prevents the ghosting screen, which tell us about "the program not responding". Windows send messages and waiting to return back to check if a message loop respond. So a message has a time stamp. Using the anti ghosting state M2000 may run programs with no refreshing for long time, without problem. But here we want the 3 downloads to work, connecting Internet (other PC, in the World Net, not a Local Net), and not blocking the "actuator", which are us, where we place the three methods, one for each object, for the downloads.
So when we get the progress event, at a speed of a modern PC, the sink created by M2000 interpreter, fire the event, calling a specific function (all the com objects send events, from a specific type sink object which call a specific function give the parameters, of which object send and what, the name of event, and the parameters. At the return of this function the param list send it back, to work for by reference type variables). So the events from com objects just interrupt the main thread when happen, not when the main thread ask a "doevents", So a thread (a M2000 thread) may interrupted, very fast. Because the functions where we serve services, in M2000 are different from normal functions, to access the module's variables/functions/modules (they called using a Call Local, passing the module's name as the name of function, so a X in module is a X in function), we have to make something to ensure that parameters from the call are written in different variables, but with same name. So we declare New before the name's to read from stack of values (each call from an event has own stack of values, so the serving function change name with module name, only to look/handle entities from module. Normal functions are closed as the modules, only local or global entities are visible. If a Module A has a local Module B, then B can't see A members, and A can't see B members.
Another thing to see here is about layers, and the split screen. On way to change split screen row, is by setting the second parameter in CLS command. So a CLS ,5 set 6th row as the top row of the down part of screen, then scrolling part. here we set at some stages different split screen row, so the last setting leave the part with numbers.
The printing routine on Layers use text with transparent background. Except the Print Over, which erase the line before print. So we can easy use it to display information to upper part of split screen, the static part. We have to erase before print, and that happen by Print Over.
Print Over, Print Part and Print Under are a set of print commands, which have some properties. All of this commands restore colors, columns, print style setting. No one of them insert a new line after the call. Print Under draw a line (as underline) to current line, then insert a new line, then print anything we have as argument list. Print Over erase the line except the horizontal line which Print Under draw. Aldo Print Over set by default one column entire width, and print style 6 (proportional text, center justify). In the picture bellow we see print over three times for progress on console and three for the form. Each time we have change the one column all row, to specific columns.
In info.gsb they are these two modules - games. The Snake (auto play), and Chess for two. The first (snake) use Greek statements, the other English (M2000 has two set of commands, Greek and the English, a command has to be in one language, but we can use commands from any language anywhere in M2000).
The Snake handle the parts of games in any console configuration, here we see the cyan BACK and a print using Console as Layer
Chess is more advanced. The console now is the lines under the chess board. The chess board and the header are drawing in the BACK layer. The BACK layer can be extended to any width and height (respecting then top limits), the LAYER and the 32 layers from LAYER 1 to LAYER 32 (when used as consoles) they have width a multiple of then base width. Also the height have rows plus line space so for proper handle we get a height smaller than total visible height. But this not happpem fro Back Layer.
For joke we can move the form by holding mouse left button on header. And each time we run the module, form a random number the program decide to change size....
Chess record each position in FEN string.We can go back to any previous move. We can replay the game, We can export the game (we can import too).
