Thorsten Froehlich wrote:

> In article <3db7bac0@news.povray.org> , Lee Begg <lln### [at] paradisenetnz>
> wrote:
> 
>> That is what I have been doing.  There is no central place of this
>> code... I think I see bits of it across atleast 5 files.
> 
> Not really.  There is a structure to it.  First you add a new
> kPOVAttrib_xxx constant in povmsgid.h, then you enter the constant and its
> option names in either or both of the tables Ini_Parser_Tab and/or
> Cmd_Parser_Table, where
> as you may guess from the existing order, order matters.  Unless you need
> kUseSpecialHandler optin.cpp will then do the parsing for you.  Now you
> only have to receive the message in povmsrec.cpp and turn it into the
> internal
> state.  To be able to send the data, extract it from the internal state in
> povmsend.cpp .  That is all.

Thanks.

That was exact what I was after.

> 
>> I guess I will muddle though it... but I would have thought that either
>> the POVRay developers would be helpful, or atleast some patch developers
>> might expalain how they when about it.
> 
> Well, as the whole code is not documented, that is how it works when
> "learning" POV-Ray.
> 
>> What do you do in terms of POVRay development?  Are you upset because you
>> are in the same boat (trying to figure out what to do with only the code
>> to help?)
> 
> No, I wrote that code :-)  There are many places that are not documented,
> not just this part (also this part is documented, just not publicly).  One
> just has to get used to it.  And occasionally a change may break something
> else.  One gets over this setback and fixes the problem; and moves on.

Well... I guess I should be a bit more careful with my code (across 3 open 
source products)  :-)

I can understand that.  Perhaps there should be a page on the website with 
gems like this one.

> 
>     Thorsten

Thanks again.

Expect a PVMPOV patch in the next week or so  :-)

Later
Lee Begg

Post a reply to this message