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

Question

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

score 0 · Answer 1 · answered Mar 11 '15 at 08:34

0

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.

answered Mar 11 '15 at 08:34

Thank you. That's the exact same answer I got from Adobe forums. The code is still not working though....I will blame it on 'old' lingo, and I just bought this book - 2nd hand from Amazon. I wonder if there's a later version? hmmm. But, thanks again Mints97. – londonbird Mar 11 '15 at 17:09
@londonbird: what error is it giving you now? Anyway, you can try looking for an old Director version (I'd shoot for Director 8 or earlier) if you really want to use examples from this book; IIRC, Lingo underwent heavy changes at some point. However, if you'll decide in favor of old Lingo, beware - you may end up making stuff that won't work with modern versions of Shockwave (its backward compatibility sucks) – Mar 11 '15 at 17:28
1

Update: I got the code to work by replacing a name of member with the cast member number. It all worked after that. Hurray for that. – londonbird Mar 11 '15 at 18:59
Hello again. I think I will stick to the latest Director 12. I contacted the author and he said he has no intention of writing anymore books with Director as he doesn't use it anymore, preferring to use AS3 and AIR. – londonbird Mar 12 '15 at 18:18
@londonbird: well, there are always other books and internet tutorials, if you really want to learn to make Shockwave stuff ;) Anyway, if my answer helped you, you can consider *accepting* it for future reference of people trying out this specific Director tutorial =) – Mar 12 '15 at 18:35

score 0 · Answer 2 · answered Apr 22 '16 at 00:51

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

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

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

2 Answers2