The editor on the Windows platform does not recognize the following SDL
keywords:

atand
clock_delta
final_clock
final_frame
frame_number
image_height
image_width
initial_clock
initial_frame
input_file_name

They are not highlighted as keywords, they do not work with Keyword Expansion,
and they do not show up in CodeList.

Post a reply to this message

On 19.07.11 21:21, Cousin Ricky wrote:
> The editor on the Windows platform does not recognize the following SDL
> keywords:
>
> atand
> clock_delta
> final_clock
> final_frame
> frame_number
> image_height
> image_width
> initial_clock
> initial_frame
> input_file_name
>
> They are not highlighted as keywords, they do not work with Keyword Expansion,
> and they do not show up in CodeList.

None of these are keywords in 3.7, so the editor is right. Some of them are 
declared variables though.

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> None of these are keywords in 3.7, so the editor is right. Some of them 
> are declared variables though.

According to the manual clock is also just built-in variable, but it
is highlighted by the editor. So there is a small inconsistency.

Post a reply to this message

On 20.07.11 00:47, Christian Froeschlin wrote:
> Thorsten Froehlich wrote:
>
>> None of these are keywords in 3.7, so the editor is right. Some of them
>> are declared variables though.
>
> According to the manual clock is also just built-in variable, but it
> is highlighted by the editor. So there is a small inconsistency.

No, there is a difference between built-in variables and declared variables. 
The former are keywords and cannot be changed by the user. The later are 
accessible by SDL just like any other declared variable.

	Thorsten

Post a reply to this message

On 7/19/2011 9:17 PM, Thorsten Froehlich wrote:
> On 20.07.11 00:47, Christian Froeschlin wrote:
>> Thorsten Froehlich wrote:
>>
>>> None of these are keywords in 3.7, so the editor is right. Some of them
>>> are declared variables though.
>>
>> According to the manual clock is also just built-in variable, but it
>> is highlighted by the editor. So there is a small inconsistency.
>
> No, there is a difference between built-in variables and declared
> variables. The former are keywords and cannot be changed by the user.
> The later are accessible by SDL just like any other declared variable.
>
> Thorsten
>
Hmm. So.. What is being said is we need a smarter parser, that 
recognizes declared values, and marks them as such (different hilighting 
than the built ins though). Seriously though, this is standard in most 
language editors, being able to recognize, especially when its a 
specific language the editor was designed for, when you have declared 
something, otherwise object oriented programming would be a total pain 
in the ass, for example.

That said, the solution is likely one of those, "We will get to it when 
we get the thing working completely, like... next version.", unless 
someone else comes along and does something about it themselves. ;)

Post a reply to this message

Thorsten Froehlich wrote:

> No, there is a difference between built-in variables and declared 
> variables. The former are keywords and cannot be changed by the user. 
> The later are accessible by SDL just like any other declared variable.

I thought the question was mostly about built-in variables,
according to the documentation anyway:

FLOAT_BUILT-IN_IDENT:
   clock | clock_delta | clock_on | final_clock | final_frame
   frame_number | initial_clock | initial_frame

So from the user's point of view it is strange that
clock_delta is treated differently from clock.

Post a reply to this message

On 20.07.11 20:20, Christian Froeschlin wrote:
> Thorsten Froehlich wrote:
>
>> No, there is a difference between built-in variables and declared
>> variables. The former are keywords and cannot be changed by the user. The
>> later are accessible by SDL just like any other declared variable.
>
> I thought the question was mostly about built-in variables,
> according to the documentation anyway:
>
> FLOAT_BUILT-IN_IDENT:
> clock | clock_delta | clock_on | final_clock | final_frame
> frame_number | initial_clock | initial_frame
>
> So from the user's point of view it is strange that
> clock_delta is treated differently from clock.

Hmm, OK, that was true for 3.6. Looks like we haven't updated the docs yet, 
assuming this is still in there...

	Thorsten

Post a reply to this message

On 20.07.11 20:16, Patrick Elliott wrote:
>> No, there is a difference between built-in variables and declared
>> variables. The former are keywords and cannot be changed by the user.
>> The later are accessible by SDL just like any other declared variable.
>>
>> Thorsten
>>
> Hmm. So.. What is being said is we need a smarter parser, that recognizes
> declared values, and marks them as such (different hilighting than the built
> ins though). Seriously though, this is standard in most language editors,
> being able to recognize, especially when its a specific language the editor
> was designed for, when you have declared something, otherwise object
> oriented programming would be a total pain in the ass, for example.
>
> That said, the solution is likely one of those, "We will get to it when we
> get the thing working completely, like... next version.", unless someone
> else comes along and does something about it themselves. ;)

This has been in the Mac editor for a long time (even though there currently 
is no official Mac 3.7). The code is fairly simple and portable. I actually 
thought it had also been in the Windows version, but maybe I am mistaken.

However, this won't actually help for some of those variables in 3.7, as 
they are implemented as declares passed on the command-line internally to 
maintain backward-compatibility with 3.6 scenes.

Of course, the more interesting feature that exists now is the ability to 
change these variables in the scene. Though I am not sue anybody makes use 
of that as of now.

The rationale behind this change is the clearer separation between parsing 
and rendering. Of course, this is just one step in a longer transition on 
that end, with a fairly open end.

	Thorsten

Post a reply to this message