londonbird
londonbird

Reputation: 45

Lingo Code "[cc]" is coming up as a fault

The game is a word search game in an advanced lingo book and the lingo code is using [cc] which is coming up as a code fault. What is wrong or is this use of [cc] obsolete? And if so, how can it be corrected?

 on getPropertyDescriptionList me
   list = [:]

   -- the text member with the words in it
   addProp list, #pWordSource,[cc]
    [#comment: "Word Source",[cc]
    #format: #text,[cc]
    #default: VOID]

 addProp list, #pEndGameFrame,[cc]
    [#comment: "End Game Frame",[cc]
    #format: #marker,[cc]
    #default: #next]

    return list
 end

Upvotes: 1

Views: 112

Answers (2)

jtnimoy
jtnimoy

Reputation: 46

I programmed in early director but have gone on to other languages in the many years since. I understand this code. The function attempts to generate a dictionary of dictionaries. in quasi-JSON:

{
  'pWordSource': { ... } ,
  'pEndGameFrame': { ... }
}

It is creating a string hash, then storing a "pWordSource" as a new key pointing to a 3 item hash of it's own. The system then repeats the process with a new key "pEndGameFrame", providing yet another 3 item hash. So just to expand the ellipses ... from the above code example:

{

  'pWordSource': { 'comment': 'Word Source', 'format': 'text', 'default': null } ,

  'pEndGameFrame': { 'End Game Frame': 'Word Source', 'format': 'marker', 'default': 'next' }

}

So I hope that explains the hash characters. It's lingo's way of saying "this is not just a string, it's a special director-specific system we're calling a symbol. It can be described in more conventional programming terms as a constant. The lingo compiler will replace your #string1 with an integer, and it's always going to be the same integer associated with #string1. Because the hash keys are actually integers rather than strings, we can change the json model to look something more like this:

{

  0: { 2: 'Word Source', 3: 'text', 4: null } ,

  1: { 2:'End Game Frame', 3: 'marker', 4: 'next' }

}

where:

0 -> pWordSource
1 -> pEndGameFrame
2 -> comment
3 -> format
4 -> default

So to mimic the same construction behavior in 2016 lingo, we use the newer object oriented dot syntax for calling addProp on property lists.

on getPropertyDescriptionList me
  list = [:]

  -- the text member with the words in it

  list.addProp(#pWordSource,[       \
          #comment: "Word Source", \
          #format: #text,          \
          #default: void           \
      ])

  list.addProp(#pEndGameFrame,[        \
          #comment: "End Game Frame", \
          #format: #marker,           \
          #default: #next             \
      ])

  return list
end

Likewise, the same reference shows examples of how to use square brackets to "access" properties, then initialize them by setting their first value.

on getPropertyDescriptionList me
  list = [:]

  -- the text member with the words in it

  list[#pWordSource] = [       \
      #comment: "Word Source", \
      #format: #text,          \
      #default: void           \
  ]

  list[#pEndGameFrame] = [        \
      #comment: "End Game Frame", \
      #format: #marker,           \
      #default: #next             \
  ]

  return list
end

And if you are still confused about what the backslashes are doing, there are other ways to make the code more vertical.

on getPropertyDescriptionList me
  list = [:]

  -- the text member with the words in it

  p = [:]
  p[#comment] = "Word Source"
  p[#format] = #text
  p[#default] = void

  list[#pWordSource] = p

  p = [:] -- allocate new dict to avoid pointer bug
  p[#comment] = "End Game Frame"
  p[#format] = #marker
  p[#default] = #next

  list[#pEndGameFrame] = p

  return list
end

Adobe Director Lingo's Property Inspector palette window, showing the property description list feature working OK

The above screenshot shows it working in Director 12.0 on OS X Yosemite.

Upvotes: 0

user3079266
user3079266

Reputation:

I guess this is code from here, right?

That seems like an older version of Lingo syntax. [cc], apparently, stands for "continuation character". It basically makes the compiler ignore the linebreak right after it, so that it sees everything from [#comment: to #default: VOID] as one long line, which is the syntactically correct way to write it.

If I remember correctly, once upon a time, the guys who made Lingo made one more crazy decision and made the continuation character look like this: ¬ Of course, this didn't print in lots of places, so some texts like your book used things like [cc] in its place.

In modern versions of Lingo, the continuation character is \, just like in C.

Upvotes: 0

Related Questions