LiveCode Builder is a language for extending LiveCode's capabilities, creating new object types as Widgets, and libraries that access lower-level APIs in OSes, applications, and DLLs.
Moderators: LCMark, LCfraser
-
trevordevore
- VIP Livecode Opensource Backer

- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
-
Contact:
Post
by trevordevore » Sat Jun 06, 2015 4:42 pm
I'm experimenting with LCB libraries that act as an interface for faceless objects. (I'm assuming that when open language arrives that it will be built on top of LCB. Is that correct?) I'm converting LCS scripts that did this before. Eventually I will want to have an open language interface for these libraries. I'm working on the getters/setters for the object properties. In LCS I just had one command for setting and one function for getting:
Code: Select all
function objectGet pObjectId, pProperty
end objectGet
command objectSet pObjectId, pProperty, pValue
end objectSet
@LCMark - I'm wondering if you know enough about how open language will be designed yet to comment on what the best approach would for what I'm doing? Will it matter if I use one get/set handler in LCB or define a different handler for each property? I want to eventually be able to write things like this:
Code: Select all
set the <property> of myObject <id> to "some value"
Will this even be possible with libraries or would we need a different interface similar to widgets but without any UI?
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
-
PaulDaMacMan
- Posts: 683
- Joined: Wed Apr 24, 2013 4:53 pm
-
Contact:
Post
by PaulDaMacMan » Thu Jun 11, 2015 7:09 pm
I too am interested in knowing more about the future of LCB & OpenLanguage. I'm interested in wrapping some existing foreign code libraries / frameworks / APIs for use with LiveCode (specifically FluidSynth and/or Core MIDI). I've heard that LCB already supports foreign language libraries if they're written in C (and later will support C++, JAVA, etc.). I've read that CoreMIDI is actually written in C (as opposed to Apple's other frameworks - ObjC) and I have some sample code for CLI-Apps written in C that make calls and receive call-backs to/from Core MIDI.
In short, I would love to see an example of wrapping some foreign code lib written in C but there doesn't seem to be any info about it yet.
T.I.A. to anyone who can shed some light.
-
trevordevore
- VIP Livecode Opensource Backer

- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
-
Contact:
Post
by trevordevore » Thu Jun 11, 2015 8:09 pm
PaulDaMacMan wrote:In short, I would love to see an example of wrapping some foreign code lib written in C but there doesn't seem to be any info about it yet.
T.I.A. to anyone who can shed some light.
@PaulDaMacMan This is a different topic then what my post is about. Can you start a new thread so we don't get any responses mixed up?
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
-
PaulDaMacMan
- Posts: 683
- Joined: Wed Apr 24, 2013 4:53 pm
-
Contact:
Post
by PaulDaMacMan » Thu Jun 11, 2015 11:54 pm
trevordevore wrote:PaulDaMacMan wrote:In short, I would love to see an example of wrapping some foreign code lib written in C but there doesn't seem to be any info about it yet.
T.I.A. to anyone who can shed some light.
@PaulDaMacMan This is a different topic then what my post is about. Can you start a new thread so we don't get any responses mixed up?
You are designing libraries for faceless objects (GUI-less?) written in LCB for future use with Open Language and want some clarification.
I want to create wrapper(s) for pre-existing libraries for GUI-less objects with LCB for future use with Open Language and want some clarification.
Basically I'm looking for this kind of info as well:
I'm wondering if you know enough about how open language will be designed yet to comment on what the best approach
So it seemed appropriate for a thread titled "Designing LCB libraries with open language in mind", but sure I could start another thread, maybe I'm misunderstanding what you're talking about.
-
trevordevore
- VIP Livecode Opensource Backer

- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
-
Contact:
Post
by trevordevore » Fri Jun 12, 2015 12:22 am
I was referring to the part where you said that in short you wanted examples of wrapping foreign code in C. That seems like a different thread topic to me.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
-
trevordevore
- VIP Livecode Opensource Backer

- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
-
Contact:
Post
by trevordevore » Thu Jun 18, 2015 5:24 pm
I've been looking at some of the .mlc files in the LC distribution. I think I can pose a more concrete question now. Based on the code I've looked at it appears that each property has a separate function. For example, <the antialias of Canvas> has the following syntax definition:
Code: Select all
syntax CanvasPropertyAntialias is prefix operator with precedence 4
"the" "antialias" "of" <mCanvas: Expression>
begin
MCCanvasGetAntialias(mCanvas, output)
MCCanvasSetAntialias(input, mCanvas)
end syntax
The only syntax I found as I glanced over the dictionary that used a variable for property names was the script object. For example, <get property Property of Object> has the following syntax definition:
Code: Select all
syntax GetPropertyOfScriptObject is statement
"get" "property" <Property: Expression> "of" <Object: Expression>
begin
MCEngineExecGetPropertyOfScriptObject(Property, Object)
end syntax
Based on this I'm guessing that unless I want to prefix all of my syntax with a keyword like <property> (once Open Language becomes generally available) then I should define a handler for each property that I want to set. Is that accurate?
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
-
LCMark
- Livecode Staff Member

- Posts: 1232
- Joined: Thu Apr 11, 2013 11:27 am
Post
by LCMark » Mon Jun 22, 2015 10:21 am
@trevordevore: At the moment syntax for properties in LCB is defined by having separate handlers for setting / getting each property - we will be making this a bit less 'low-level' at some point though by adding a 'property syntax' clause (much like property clauses in widgets) and at that point we could probably give the choice between whether to call a dispatch function (taking the property name), or individual functions. However, I think that separate getters / setters should be preferred as we've found them easier to maintain in the engine (since the 7 refactor).