I'm still using CCSM MUMPS until now (July 2021) dosbox windows

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, July 24, 2021 at 6:16:17 PM UTC-7, solo...@gmail.com wrote:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

What a kick. Used about 500 copies to build a solution for a contact center...Because it had no tcp support, it was replaced with MSM.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Em sábado, 24 de julho de 2021 às 22:16:17 UTC-3, solo...@gmail.com escreveu:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, August 1, 2021 at 7:13:54 PM UTC-4, flaviof...@hotmail.com wrote:

Em sábado, 24 de julho de 2021 às 22:16:17 UTC-3, solo...@gmail.com escreveu:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

That was the Mumps I learned on, and implemented the first production system I wrote on. Good Stuff! I miss David Brown, he was good people.
Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Em terça-feira, 3 de agosto de 2021 às 18:33:55 UTC-3, OldMster escreveu:

On Sunday, August 1, 2021 at 7:13:54 PM UTC-4, flaviof...@hotmail.com wrote:

Em sábado, 24 de julho de 2021 às 22:16:17 UTC-3, solo...@gmail.com escreveu:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

That was the Mumps I learned on, and implemented the first production system I wrote on. Good Stuff! I miss David Brown, he was good people.
Mark

Hi Mr.Mark,

Good to know that, It must have been good times. The oldest M implementation that I have in my collection is MSM-PC 2.27.
I'm really curious about what was there before that.

Cheers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.08.21 01:17, Flávio Fornazier wrote:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

That was the Mumps I learned on, and implemented the first production system I wrote on. Good Stuff! I miss David Brown, he was good people.

Good to know that, It must have been good times. The oldest M implementation that I have in my collection is MSM-PC 2.27.
I'm really curious about what was there before that.

In 1977, as I started to learn MUMPS, I have used to use V4B on a
PDP-11/34 with just a few KB (Kilo-, not Mega- or even Gigabyte!) of RAM
memory (a real core memory). Long long ago.

Regards,
Julius

--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, August 4, 2021 at 1:09:08 AM UTC-7, retired developer wrote:

On 04.08.21 01:17, Flávio Fornazier wrote:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

That was the Mumps I learned on, and implemented the first production system I wrote on. Good Stuff! I miss David Brown, he was good people.

Good to know that, It must have been good times. The oldest M implementation that I have in my collection is MSM-PC 2.27.
I'm really curious about what was there before that.

In 1977, as I started to learn MUMPS, I have used to use V4B on a
PDP-11/34 with just a few KB (Kilo-, not Mega- or even Gigabyte!) of RAM memory (a real core memory). Long long ago.

Regards,
Julius

--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

Think anyone would be interested in a loosely coupled GUI for the various M technologies.
Haven't looked at M for about 10 years. Used Cache as the server in a fairly robust client-server topology. Desktops (about 500+) provided the platform for our teleservices front-end, with a custom graphical user interface. This implementation was
supported by only 5 jobs; sort of circumvented Intersystems licensing for such systems. (Terry Ragon winked)
Anyway, have no idea what is available or in use beyond MSM Workstation and would be interested in thoughts. The last version of CCSM attempted a GUI implementation. However, it was not stable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Em quarta-feira, 4 de agosto de 2021 às 18:13:19 UTC-3, Rick H escreveu:

On Wednesday, August 4, 2021 at 1:09:08 AM UTC-7, retired developer wrote:

On 04.08.21 01:17, Flávio Fornazier wrote:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

That was the Mumps I learned on, and implemented the first production system I wrote on. Good Stuff! I miss David Brown, he was good people.

Good to know that, It must have been good times. The oldest M implementation that I have in my collection is MSM-PC 2.27.
I'm really curious about what was there before that.

In 1977, as I started to learn MUMPS, I have used to use V4B on a PDP-11/34 with just a few KB (Kilo-, not Mega- or even Gigabyte!) of RAM memory (a real core memory). Long long ago.

Regards,
Julius

--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

Think anyone would be interested in a loosely coupled GUI for the various M technologies.
Haven't looked at M for about 10 years. Used Cache as the server in a fairly robust client-server topology. Desktops (about 500+) provided the platform for our teleservices front-end, with a custom graphical user interface. This implementation was

supported by only 5 jobs; sort of circumvented Intersystems licensing for such systems. (Terry Ragon winked)

Anyway, have no idea what is available or in use beyond MSM Workstation and would be interested in thoughts. The last version of CCSM attempted a GUI implementation. However, it was not stable.

Hi Mr.Rick,

Do you mean a modern desktop framework based on MWAPI for all current M implementations? Although MiniM has activex, libs and examples for a lot of modern languages, this week I was thinking talking to Mr.Eugene Karataev about it. Hey Mr.Eugene! Are you
there? Anyway, please tell us more about your idea.

Best Regards.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Do you mean a modern desktop framework based on MWAPI for all current M implementations? Although MiniM has activex, libs and examples for a lot of modern languages, this week I was thinking talking to Mr.Eugene Karataev about it. Hey Mr.Eugene! Are

you there? Anyway, please tell us more about your idea.

Main idea is to use Lazarus as component-oriented windowing base.
This tool allow to create form editors, get and save form definition where we want and to create this forma at runtime. Form definition is text like this:
object Form1: TMForm
Left = 581
Height = 426
Top = 194
OnCreate = FormCreate
OnDestroy = FormDestroy
OnClose = FormClose
object btnFile: TButton
Left = 248
Height = 25
Caption = '...'
OnClick = btnFileClick
TabOrder = 4
end
object edtRoutines: TMemo
Left = 75
Height = 60
Top = 151
Width = 169
TabOrder = 5
end
end

This definition can be imported by custom tool into global and read from there by form player.
Player can create form by this definition and on each event call like button pressed see the name
of event handler assosiated in form development and can know arguments passed from the Lazarus.
So just call the server and wait callback calls from the server.
Server can pass to player commands like set or get property values or command to call function.
Test code which I run to test was:
test ; place here default event handlers for the test MForm
; Self is passed variable, mean form reference
; Sender are references to event source objects
FormCreate(Sender)
s ^mftrace($i(^mftrace))="FormCreate("_Sender_"), Self="_Self
q
FormDestroy(Sender)
s ^mftrace($i(^mftrace))="FormDestroy("_Sender_"), Self="_Self
q
FormClose(Sender,CloseAction)
; CloseAction passed by reference
s ^mftrace($i(^mftrace))="FormClose("_Sender_"), Self="_Self_", CloseAction="_CloseAction
; to prevent window closing uncomment this line
; s CloseAction="caNone"
q
btnFileClick(Sender)
; get object reference to edit component
n edtName=$$CHILD^%MF(Self,"edtName")
; call function Clear
d PROC^%MF(edtName,"Clear")
; get object reference of child component
n edtReport=$$CHILD^%MF(Self,"edtReport")
; get object reference to property Lines of component
n Lines=$$GET^%MF(edtReport,"Lines")
; call function Add of Lines property of edtReport component
n tmp=$$FUNC^%MF(Lines,"Add",$h)
q
; s ^mftrace($i(^mftrace))="btnFileClick("_Sender_"), Self="_Self
n caption=$$GET^%MF(Self,"Caption")
n edtName=$$CHILD^%MF(Self,"edtName")
d SET^%MF(edtName,"Text",caption)
n edtReport=$$CHILD^%MF(Self,"edtReport")
n Lines=$$GET^%MF(edtReport,"Lines")
s ^mftrace($i(^mftrace))="btnFileClick("_Sender_"), Lines="_Lines
q
btnImportClick(Sender)
s ^mftrace($i(^mftrace))="btnImportClick("_Sender_"), Self="_Self
n edtName=$$CHILD^%MF(Self,"edtName")
d SET^%MF(edtName,"Text",$zv)
d SET^%MF(Self,"Caption","Hello, MUMPS Forms!")
q

Here $$CHILD^%MF gets reference to child component by name,
PROC^%MF calls procedure without returning value,
$$GET^%MF reads property value and SET^%MF sets the value.
so, the code
n edtReport=$$CHILD^%MF(Self,"edtReport")
n Lines=$$GET^%MF(edtReport,"Lines")
n tmp=$$FUNC^%MF(Lines,"Add",$h)
gets the reference to child component edrReport (Memo component),
gets reference to object property Lines and calls funtion of Lines Add and pass $h value.
And player in multiline editor shows one more line with $h.

New form can be created by
s child=$$NEW^%MF(“frmChild”)

I tests very simple stand wihich supports only some components and events for MiniM on Windows and
for GT.M on Linux, and this executes without any code changes. Of course, I cannot use
new var=expr in GT.M.

Full project development requires many and many time to implement each event type. and function.
And make tests, and use many usable components, and develop form designer, and import-export tools, documentation, examples, installers, user security model, secure network messages. And I does not see all problems now )))

This project is like Java or DotNET wrappers to objects of OS-specific GUI but with the M on the server which control the form player on the client computer. Like M server control the telnet on the client side.

I know that this can be done but know too that this gets many time.

Eugene Karataev.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Em sexta-feira, 6 de agosto de 2021 às 18:35:45 UTC-3, Eugene Karataev escreveu:

Do you mean a modern desktop framework based on MWAPI for all current M implementations? Although MiniM has activex, libs and examples for a lot of modern languages, this week I was thinking talking to Mr.Eugene Karataev about it. Hey Mr.Eugene! Are

you there? Anyway, please tell us more about your idea.

Main idea is to use Lazarus as component-oriented windowing base.
This tool allow to create form editors, get and save form definition where we want and to create this forma at runtime. Form definition is text like this:
object Form1: TMForm
Left = 581
Height = 426
Top = 194
OnCreate = FormCreate
OnDestroy = FormDestroy
OnClose = FormClose
object btnFile: TButton
Left = 248
Height = 25
Caption = '...'
OnClick = btnFileClick
TabOrder = 4
end
object edtRoutines: TMemo
Left = 75
Height = 60
Top = 151
Width = 169
TabOrder = 5
end
end

This definition can be imported by custom tool into global and read from there by form player.
Player can create form by this definition and on each event call like button pressed see the name
of event handler assosiated in form development and can know arguments passed from the Lazarus.
So just call the server and wait callback calls from the server.
Server can pass to player commands like set or get property values or command to call function.
Test code which I run to test was:
test ; place here default event handlers for the test MForm
; Self is passed variable, mean form reference
; Sender are references to event source objects
FormCreate(Sender)
s ^mftrace($i(^mftrace))="FormCreate("_Sender_"), Self="_Self
q
FormDestroy(Sender)
s ^mftrace($i(^mftrace))="FormDestroy("_Sender_"), Self="_Self
q
FormClose(Sender,CloseAction)
; CloseAction passed by reference
s ^mftrace($i(^mftrace))="FormClose("_Sender_"), Self="_Self_", CloseAction="_CloseAction
; to prevent window closing uncomment this line
; s CloseAction="caNone"
q
btnFileClick(Sender)
; get object reference to edit component
n edtName=$$CHILD^%MF(Self,"edtName")
; call function Clear
d PROC^%MF(edtName,"Clear")
; get object reference of child component
n edtReport=$$CHILD^%MF(Self,"edtReport")
; get object reference to property Lines of component
n Lines=$$GET^%MF(edtReport,"Lines")
; call function Add of Lines property of edtReport component
n tmp=$$FUNC^%MF(Lines,"Add",$h)
q
; s ^mftrace($i(^mftrace))="btnFileClick("_Sender_"), Self="_Self
n caption=$$GET^%MF(Self,"Caption")
n edtName=$$CHILD^%MF(Self,"edtName")
d SET^%MF(edtName,"Text",caption)
n edtReport=$$CHILD^%MF(Self,"edtReport")
n Lines=$$GET^%MF(edtReport,"Lines")
s ^mftrace($i(^mftrace))="btnFileClick("_Sender_"), Lines="_Lines
q
btnImportClick(Sender)
s ^mftrace($i(^mftrace))="btnImportClick("_Sender_"), Self="_Self
n edtName=$$CHILD^%MF(Self,"edtName")
d SET^%MF(edtName,"Text",$zv)
d SET^%MF(Self,"Caption","Hello, MUMPS Forms!")
q

Here $$CHILD^%MF gets reference to child component by name,
PROC^%MF calls procedure without returning value,
$$GET^%MF reads property value and SET^%MF sets the value.
so, the code
n edtReport=$$CHILD^%MF(Self,"edtReport")
n Lines=$$GET^%MF(edtReport,"Lines")
n tmp=$$FUNC^%MF(Lines,"Add",$h)
gets the reference to child component edrReport (Memo component),
gets reference to object property Lines and calls funtion of Lines Add and pass $h value.
And player in multiline editor shows one more line with $h.

New form can be created by
s child=$$NEW^%MF(“frmChild”)

I tests very simple stand wihich supports only some components and events for MiniM on Windows and
for GT.M on Linux, and this executes without any code changes. Of course, I cannot use
new var=expr in GT.M.

Full project development requires many and many time to implement each event type. and function.
And make tests, and use many usable components, and develop form designer, and import-export tools, documentation, examples, installers, user security model, secure network messages. And I does not see all problems now )))

This project is like Java or DotNET wrappers to objects of OS-specific GUI but with the M on the server which control the form player on the client computer. Like M server control the telnet on the client side.

I know that this can be done but know too that this gets many time.

Eugene Karataev.

Hi Mr.Eugene,

Could you post %MF routine related to above test?

Thank you in advanced.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Could you post %MF routine related to above test?

CHILD(Parent,Name)
q $$cb^%srv($lb("ch",Parent,Name))
SET(Obj,Name,Value)
d wo^%srv($lb("sp",Obj,Name,Value))
q
GET(Obj,Name)
q $$cb^%srv($lb("gp",Obj,Name))
PROC(Obj,Name,Args...)
n params s params=""
n i f i=1:1:Args s params=params_$lb(Args(i))
d wo^%srv($lb("pr",Obj,Name,params))
q
FUNC(Obj,Name,Args...)
n params s params=""
n i f i=1:1:Args s params=params_$lb(Args(i))
q $$cb^%srv($lb("fu",Obj,Name,params))
NEWFORM()
q ""

It is test only )))
On client side I wait commands like "gp" or "pr".
Server calls form's player via wo^%srv for non-waitable interaction and via $$cb^%srv when we need confirmed answer. I think, all interactions can fire callback calls to server on events, so all
calls from server to client must be waitable.

Eugene Karataev

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, August 4, 2021 at 10:10:46 PM UTC-7, flaviof...@hotmail.com wrote:

Em quarta-feira, 4 de agosto de 2021 às 18:13:19 UTC-3, Rick H escreveu:

On Wednesday, August 4, 2021 at 1:09:08 AM UTC-7, retired developer wrote:

On 04.08.21 01:17, Flávio Fornazier wrote:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

That was the Mumps I learned on, and implemented the first production system I wrote on. Good Stuff! I miss David Brown, he was good people.

Good to know that, It must have been good times. The oldest M implementation that I have in my collection is MSM-PC 2.27.
I'm really curious about what was there before that.

In 1977, as I started to learn MUMPS, I have used to use V4B on a PDP-11/34 with just a few KB (Kilo-, not Mega- or even Gigabyte!) of RAM memory (a real core memory). Long long ago.

Regards,
Julius

--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

Think anyone would be interested in a loosely coupled GUI for the various M technologies.
Haven't looked at M for about 10 years. Used Cache as the server in a fairly robust client-server topology. Desktops (about 500+) provided the platform for our teleservices front-end, with a custom graphical user interface. This implementation was

supported by only 5 jobs; sort of circumvented Intersystems licensing for such systems. (Terry Ragon winked)

Anyway, have no idea what is available or in use beyond MSM Workstation and would be interested in thoughts. The last version of CCSM attempted a GUI implementation. However, it was not stable.

Hi Mr.Rick,

Do you mean a modern desktop framework based on MWAPI for all current M implementations? Although MiniM has activex, libs and examples for a lot of modern languages, this week I was thinking talking to Mr.Eugene Karataev about it. Hey Mr.Eugene! Are

you there? Anyway, please tell us more about your idea.

Best Regards.

No. MWAPI is way to slow...and understandably so. And it does not provide for the construction of alternative form of window management. The solution will leverage the technology of tcl\tk (what's that?), and will work in very much the same way as qt -
but without the need to link to an event que or loads of libraries.
Asking who uses tcl\tk is like asking who uses mumps -
Well the medical community is steeped in M tech; and those little guys now moving around Mars, and the guidance system that help get them there .... tcl\tk.
Anyone with more than half a brain would be using tcl\tk instead of python. No apologies.

The CCSM implementation, though never stable, is an example of 'a' way that I think is better, faster and less complex.

The free \donor version would provide for the construction and execution of a GUI as a give back to the community.
Addition of speech recognition; text to speech and multimedia - audio, video - fee.

The solution is not a wet dream; it has been commercialized. examples on verbaltransactions.com

Here is an example of two buttons on a toplevel form. Note that in this instance, the controls take on the visual characteristics of the users Win 10 window theme.
# instantiate a form
write ".toplevel .myform -width 80% -height 50% -title {Button Selection}
# instantiate two controls
write "button .myform.b1 -text Continue -state normal -action {some mumps code that is invoked when button is selected}
write "button .myform.b2 -text Ok -state disabled -action {some mumps code that is invoked when button is selected}
# present in any of three forms of window management
# pack -
write "pack .myform.b1 -side left"
write "pack ..myformb2 -side right"
# grid -
write "grid .myform.b1 .myform.b2"
# place -
write "place .myform.b1 -xpos 20points -ypos 40points"
write "place .myform.b2 xpos 80 points -ypos 40points"

Note the relative sizing, and use of points to spec location. Relative positioning is possible, also.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, August 10, 2021 at 2:22:45 PM UTC-7, Rick H wrote:

On Wednesday, August 4, 2021 at 10:10:46 PM UTC-7, flaviof...@hotmail.com wrote:

Em quarta-feira, 4 de agosto de 2021 às 18:13:19 UTC-3, Rick H escreveu:

On Wednesday, August 4, 2021 at 1:09:08 AM UTC-7, retired developer wrote:

On 04.08.21 01:17, Flávio Fornazier wrote:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows >>> Wow Mr.Solo! It's unbelievable! =)

I really don't have CCSM in my M collection. Could you send me an old trial copy (if you have one) to avoid licensing troubles?

Thank you in advanced.

That was the Mumps I learned on, and implemented the first production system I wrote on. Good Stuff! I miss David Brown, he was good people.

Good to know that, It must have been good times. The oldest M implementation that I have in my collection is MSM-PC 2.27.
I'm really curious about what was there before that.

In 1977, as I started to learn MUMPS, I have used to use V4B on a PDP-11/34 with just a few KB (Kilo-, not Mega- or even Gigabyte!) of RAM
memory (a real core memory). Long long ago.

Regards,
Julius

--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

Think anyone would be interested in a loosely coupled GUI for the various M technologies.
Haven't looked at M for about 10 years. Used Cache as the server in a fairly robust client-server topology. Desktops (about 500+) provided the platform for our teleservices front-end, with a custom graphical user interface. This implementation was

supported by only 5 jobs; sort of circumvented Intersystems licensing for such systems. (Terry Ragon winked)

Anyway, have no idea what is available or in use beyond MSM Workstation and would be interested in thoughts. The last version of CCSM attempted a GUI implementation. However, it was not stable.

Hi Mr.Rick,

Do you mean a modern desktop framework based on MWAPI for all current M implementations? Although MiniM has activex, libs and examples for a lot of modern languages, this week I was thinking talking to Mr.Eugene Karataev about it. Hey Mr.Eugene! Are

you there? Anyway, please tell us more about your idea.

Best Regards.

No. MWAPI is way to slow...and understandably so. And it does not provide for the construction of alternative form of window management. The solution will leverage the technology of tcl\tk (what's that?), and will work in very much the same way as qt -

but without the need to link to an event que or loads of libraries.

Asking who uses tcl\tk is like asking who uses mumps -
Well the medical community is steeped in M tech; and those little guys now moving around Mars, and the guidance system that help get them there .... tcl\tk.
Anyone with more than half a brain would be using tcl\tk instead of python. No apologies.

The CCSM implementation, though never stable, is an example of 'a' way that I think is better, faster and less complex.

The free \donor version would provide for the construction and execution of a GUI as a give back to the community.
Addition of speech recognition; text to speech and multimedia - audio, video - fee.

The solution is not a wet dream; it has been commercialized. examples on verbaltransactions.com

Here is an example of two buttons on a toplevel form. Note that in this instance, the controls take on the visual characteristics of the users Win 10 window theme.
# instantiate a form
write ".toplevel .myform -width 80% -height 50% -title {Button Selection}
# instantiate two controls
write "button .myform.b1 -text Continue -state normal -action {some mumps code that is invoked when button is selected}
write "button .myform.b2 -text Ok -state disabled -action {some mumps code that is invoked when button is selected}
# present in any of three forms of window management
# pack -
write "pack .myform.b1 -side left"
write "pack ..myformb2 -side right"
# grid -
write "grid .myform.b1 .myform.b2"
# place -
write "place .myform.b1 -xpos 20points -ypos 40points"
write "place .myform.b2 xpos 80 points -ypos 40points"

Note the relative sizing, and use of points to spec location. Relative positioning is possible, also.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, July 24, 2021 at 8:16:17 PM UTC-5, solo...@gmail.com wrote:

I'm still using CCSM MUMPS until now (July 2021) dosbox windows

In the early 90's I was living in Houston and got to visit the offices of M-Global. Someone (David Brown?) demonstrated their M version on the Mac. I remember a slide bar being "attached" to a variable, so that when you moved the slide bar, it changed
the variable value and vice versa. Also had a copy of CCSM at one time.

Very nice.


Steve

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)