Bay Six Software Forum Index Bay Six Software
Beyond the Basics
 FAQFAQ   SearchSearch   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Experiment - Controls & arrays

Post new topic   Reply to topic    Bay Six Software Forum Index -> ViviFire language
View previous topic :: View next topic  
Author Message
Site Admin

Joined: 01 Jul 2005
Posts: 798

PostPosted: Mar 18th, 2012, 1:01am    Post subject: Experiment - Controls & arrays Reply with quote

This is another thought experiment to gauge potential users' reactions to possible syntax.

Assuming VF will declare controls in a fashion similar to LB, it will need to use arrays of many different object types. The following examples concentrate on menus.

First, a simple menu in LB might look like
Menu #File, "&File", "&Open...", FileOpen, |, "E&xit", FileExit

The same code should work exactly the same in VF. However, that syntax is rather hard to read and limits the addition of new features.

Here's basically the same menu declared with some different syntax.
begin Menu #File, "&File"
   "&open", FileOpen, #Key Ctrl("O")
   "E&xit", FileExit
end Menu

The Begin keyword introduces an object declaration that takes an array as its last parameter. Each element in the array is written on a single line. The declaration terminates with an End X, where X is the type of object.

The only difference between the first example and the second is that the latter adds "Ctrl+O" to the first menu item. The third parameter is optional and is being passed the result of the Ctrl() method that #Key implements.

The vertical bar ("|") in VF is a synonym for #Null, the value of an uninitialized object handle. The symbol can be written with any number of trailing hyphens. Its meaning depends on the object it's passed to. For a menu, it follows LB's convention of creating a separator.

The final example creates a "zoom" menu that might be used in a document viewing/editing application to control the size of the text and/or graphics on the screen.
begin Menu #Zoom, "&Zoom"
   "Zoom &in", ZoomIn, #Key Ctrl("+")
   "Zoom &out", ZoomOut, #Key Ctrl("-")
   begin RadioGroup(Number), ZoomBy, 100
      "&50%", 50
      "&75%", 75
      "1&00%", 100 ' the default as specified above
      "&150%", 150
      "&200%", 200
      "&400%", 400
   end RadioGroup
end Menu

Here RadioGroup inherits from the same base class as MenuItem which allows it to be used in its place. Additionally, RadioGroup is a parameterized type which is passed the type of the key associated with each item. Its two "normal" parameters are (1) a shared event handler that will be passed the clicked item's key, and (2) the key of the default item.

Back to top
View user's profile Send private message Send e-mail
Full Member

Joined: 20 Aug 2007
Posts: 161
Location: Austria

PostPosted: Mar 18th, 2012, 10:49am    Post subject: Re: Experiment - Controls & arrays Reply with quote

I like the block style, since it is really clear about what things belong together.

The rest of the syntax should be easy to learn too.


Any code I post can be freely used, just give credit.
Back to top
View user's profile Send private message
Junior Member

Joined: 01 Nov 2007
Posts: 21

PostPosted: May 15th, 2012, 3:12am    Post subject: Re: Experiment - Controls & arrays Reply with quote

I have seen similar syntax in thinBASIC for creating controls, windows, and menus. One down-side to this is that all GUI functionality is integrated into the language and doesn't make it easy to use with API calls.

In my idea of the "perfect language", I would like to use a library written in said language that encapsulates the local system's API calls into a GUI library, just for the sake of having a powerful, minimal language that allows the users to build off of it by giving access to the local operating system's APIs.

If named parameters were utilized, creating a GUI for beginners would be trivial.


myButton = GuiLib_CreateButton(label:"My Button", x:10, y:10, color:"white", eventHandler:myFunction)

Mandatory named parameters are no fun. In which case, if the developer left the parameter names out, it would default to the parameter order in the function's declaration. Perhaps an "optional" keyword could be used to specify which parameters were optional if optional parameters will be supported.

Even better, if modules could utilize code grouping (i.e., namespaces), we could use the dot syntax.


btnHandle = SomeGuiLib.CreateButton( ...

Edit: Further reading reveals that you've already been thinking about modules. Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Bay Six Software Forum Index -> ViviFire language All times are GMT
Page 1 of 1
Jump to:  
Quick Reply
   Shortcut keys: Alt+Q to activate, Alt+P to preview, Alt+S to submit
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Lo-Fi Version
Powered by phpBB © 2001, 2005 phpBB Group