Messages

[not]

  Perhaps you misunderstood my comment.  The Ductch were not responsible for brining it up again, they were the ones to stand up and say "No! to software patents", for which they shold be commended IMHO. 

Ishmael,

I currently do the same as you and have done it Strazer's way in the past.  Strazer's way is probably better for beginners, however it is mostly a matter of personal preference.  In either case, I still enter braces in pairs so that they are always matched.  The only time I have any possibility of errors is when clipping stuff out of existing code.   Entering new code for me is virtually error free, with regard to mismatched braces.   Getting new code to do what I want is another matter entirely. 

I always enter the braces in matching pairs.  For example if I write "{" then I immediately put "}" on the next line.  After that I then fill-in code between the two matching braces.  Just get in the habit of doing it that way and you will hardly ever have a mis-matched brace problems.   If you think it takes too long to hit the Home and UpArrow keys, just think how long and hard it is to find a mis-matched brace. 

*** Edit *** spelling

cardician,

I you would like to contribute to the current Demo Quest project let me know and I'll hook you up 

RickJ

I've been following this for a while.   It's kind of bizzare how the EU works.   Apparently there is a way to pass things like software patents into law without the approval of the EU palimentary body or any member country's parliment.   My understanding is that the "Software Patent Directive" was put on the Agriculture Council's agenda so that they could approve it without parlimentary approval.   Poland opposed it, about a month ago.
http://www.groklaw.net/article.php?story=20041221102644104

It was somehow resurected recently and again it was not accepted, thanks to the Dutch, and will now be debated in the parliment.
http://www.groklaw.net/article.php?story=20050211133435297

Apparently Bill Gates gave Denmark an ultimateum, vote for patents or else.  MS now say that it wasn't blackmail but don't deny talking about not employing anyone there if they voted  against the patent thing.  You can read about it here: http://www.groklaw.net/article.php?story=20050215071109231

So what's the big deal with software patents?   Well the problem is that mathematical algorithms, numbers, etc are not patentable or copyrightable.   Ever wonder why Intel now name their chips things like Pentium instead of 80586?   Software is in a sennse just a mathematical expression, a sequence of mathematical and loical operations so it's questionable if it should be patentable for this reason.  Also, in the US, software patents are given too freely and many are invalid because they are not unique inventions or they have been in use for a long time.  Here is a more indepth article
http://www.groklaw.net/article.php?story=2005010406110017
http://www.groklaw.net/article.php?story=2005011407083826

This is part of a much bigger battle between companies and people who support open source software and those who don't.   Microsoft intends to threaten Linux users with patent infringement law suits.   
http://www.groklaw.net/article.php?story=20041118073308709

IBM and to a lesser extent SUN are on the other side of the equation.  Both have recently made something like 1000 patents available for use by open source developers.   It appears that IBM is prepared to take on Microsoft  in court and to use their patent portfolios to counter sue MS.  I guess the patent sword cuts both ways.   
http://www.groklaw.net/article.php?story=20050110235654673
http://www.groklaw.net/article.php?story=20050126023359386

IBM is current defending a law suit brought by the SCO Group.  SCO claimed that IBM had violated their copyright by their contributions to Linux It's been going on for almost two years now and SCO has yet to  present any  evidence of their allegations.   So they keep asking for more and more discovery materials.  Their most recent request has been approved but the judge made it clear that it this is the last.  IBM has filed a counter suit and asked for summary judgement (i.e asked the judge to find in their favor based on the evidence presented and the law, without going to trial).  In the judge's most recent ruling he denied the request because discovery is still in progress but ruled that IBM can renew their request or submit a new one when discovery is complete.  In this ruling the judge scolded SCO for it's antics and made it clear that so far SCO has not presented any evidence to backup their claim.  IMHO, IMB is creaming SCO and will eventually win big time. 
http://www.groklaw.net/article.php?story=20050210075456474

So what's the tie-in with Microsoft?   Microsoft gave SCO 80+ million dollars to help fund the lawsuit.  They also got another company Baystar (or Bay something) to heavily invest in SCO.  Also Microsoft paid additional sums of money to license SCO's copyrights; except those are supposedly UNIX copyrights and MS is not a UNIX house.  Further SCO is involved in a lawsuit with NOVEL who claims that SCO does not even own the copyrights they are claiming and for which they have licensed to Microsoft.  Btw, Novel recently bought out SuSE Linux, so they apparently are on the other side of the equation along with IBM, SUN and other.   

I have been following this over at GROKLAW.  They have regular comentary from lawyers and other knowlegable people.  And.... the name of the founder is Pamela  Jones   

Home Page - http://www.groklaw.net/index.php
Archive Page -  http://www.groklaw.net/staticpages/index.php?page=20030831173953678

So, to answer the question, I don't think CJ has to worry yet as there are bigger fish to fry.   However, I would sleep much better if there were a native Linux version of the AGS editor. 

[Programming Conventions]

If it becomes a problem, then some sort of native dependency support would be a good idea. However, I don't forsee there being lots of modules with dependencies since as I see it modules will generally be contained as a unit and not rely on external things.

Yeah, I'm not certain how things will go but I agree it obviously isn't a high priority feature for now. Sorry if it sounded like an instant request, I didn't want to even mention it at first, but eventually couldn't resist.

We're thrilled to have a module mechanism and trying to be thorough in our review.   Likely we will end up at the end of this process with a wish list containing items like this.   You rightly point out, that it will become appparent, in due time, which, if any of these are meritorious.   

Agree.  have you ever heard the phrase "It's close enough for goverment work!"

... Which also as well brings us back to the naming conventions, GUIs now...

Yeah you mean like it's as usual "close enough"?

Yeah, that's pretty close to the meaning.     Goverments always spend too much money for everything and usually don't care much about the quality. 

Programming Conventions

After reading your other comments on the subject I like the IniFile_VERSION scheme very much.   The longer macro names (i.e. IniFile_VERSION_100, etc) also make more sense to me now as well.  So I am persuaded that we should go with this.

I'm glad you liked it! Still, the case hasn't been closed so if anyone have any toughts on how this approach can be improved/enhanced, please let us know.

I shall also  listen...

I agree, but I don't think that will happen this go around though.  I wish we were able to read and write the fields in the Module Manager as well.   Then I could make sure the version number there matched what's in the header etc.

Hehe, what we should only worry about is to bring anyone who follows the guidelines to remember to update the module's version info as well as the version macros themselves, that's for sure. I appreciate one may wish it to be semi-automatic at least but currently there are three steps to pass -- add a new macro, change other macro value and finally don't forget to reflect the version number in the appropriate property to be displayed next to the module name.

Actually, I think I can get the Module Manager's version number out of the SCM file, while extracting the documentation.  I could then,  perhaps verify that all three steps have been done correctly?

He didn't say if or when he would do the same for modules.  At the time I assumed that he would do so eventually, however, in light of what we are doing I think it would be a good idea to specifically request it. What do you think?

Having some sort of a module template would be nice, I agree yeah. Implementing it, again, depends on how badly it is needed for the moment, I guess.

I think put this on our wish list and at the end we can maybe llist them in orfer of importance as is our opinion and then let nature take it's course.

Except that you have already persuaded me that the longer macro names are better.

Hehe, but I didn't know for sure if I would do. 

Hehe... this could get circular

However file names can still include the version number like this IniFile_V200.zip.

Yeah, I'm all for it too.

Cool  8)

Oh yeah, now I see the flaw.  There is the possibility of name collsions, so I think this is not such a good idea, just using normal global variables are  probably a better idea.

I think sometimes it may be useful. Yep, it's mostly when there is no a struct supposed to be, so it can then be used for grouping both the global functions and variables as you described.

I think your approach, using static functions and global variables is a better solution.  For example in the actual IniFile module I use IniFile as the main struct name.  I could still add static functions as you suggest without any problems.  With my suggestion I would run into a naming problem, in that I coldn't use IniFile for both the struct name and the instance of the struct.   So, Yeah some could do what I suggest if they had a really good reason, but  otherwise they would be better using static functions.   Maybe we put a request for static variables in the wish list also.
======

Ok!  It looks like we have settled many issues.  I'm sure others will come up soon enough.   Back to work now...

I can't reproduce the problem at all. Strangely enough, it was happening in a similar way to the .PreviousRoom thign I mentioned earlier: and as soon as I quit AGS and restarted it, the problem went away.... I think there is actually a bug in there: not on any specific method, but rather having AGS open editing a long time somehow screws up the room script compilation!!!

I have been heavily using the module manager and it works great.   I experienced a couple of crashes using beta-15 but haven't seen any with beta-16.   The crashes occured during long AGS Editor sessions when doing " close module script => close module manager => test game".   

This sounds a lot like the crash I experienced a a while back.  I also had the editor open for a long time but haven't had a problem since.

[Documentation]

Documentation

Any of the following variations of "Reference" are acceptable and probably the best one is your suggestion of "IniFile Reference", where IniFile is the module name of course.

Ok, it's almost resolved here. Whatever it will be named but it's only a single section name to think of, that's relieving.

Agree.  have you ever heard the phrase "It's close enough for goverment work!" 

Scrop, do you know of any HTML docs similar to what we are proposing that we can use as a starting point or example of the kinds of things that will be required?

Not quite, at the moment, but I'll see if I can find something relevant.

I surfed around last night for examples of API type documents and how they show function proto-types, code examples, etc.   Since we pretty much settled on the organization, we only need some examples of how different kinds of things can be presented just to get a discussion started.  Maybe SSH has knows of some examples. 

Programming Conventions

No,  no, no.  I was making a joke with the language.  Sorry if the humor didn't translate well.  I didn't mean to imply anything about macro naming or anything.  I just thought it ironic and funny that the mis-spelling made me think of the word "muddle" in the context of the discussion.  I just thought to share my amusement with you.

Hehe, no I certainly got the joke but, the funny thing is, it also incited me to re-think the issue and finally to come up the IniFile_VERSION-as-a-name thingy that I should have thought of in the first place actually.

Hehe, funny how things work out sometimes.  After reading your other comments on the subject I like the IniFile_VERSION scheme very much.   The longer macro names (i.e. IniFile_VERSION_100, etc) also make more sense to me now as well.  So I am persuaded that we should go with this.   

What I really hope for, is that these macros are temporary. If in a future version of AGS it were possible to check conditions while pre-processing then these additional macros would become obsolete but the scheme would still work:

// if the module is here but the version is too old:
#if IniFile_VERSION < 102
#error IniFile version 1.02 or higher required!
#ifndef

Yeah, that would be a really cool way of handling it.   

By the way, it should be noted that in any case a new version of a module should also support functionalities of previous versions as well, i.e. the exposed but obsolete functionality should not be removed in order to ensure all dependent modules would work correctly. Such functionality can however be hidden from the autocomplete feature so that the chance it will be used in future would be minimal.
This would make modules backward compatible.

Very true.  We need to remember to make this clear in any guidelines we make.

And to be honest the more I think about it the more it seems to me that such dependence checking is to be better supported natively by the editor because it could then also sort the modules list as necessary. I can already foresee difficulties with arranging them manually in case of a large number of dependent modules.

I agree, but I don't think that will happen this go around though.  I wish we were able to read and write the fields in the Module Manager as well.   Then I could make sure the version number there matched what's in the header etc. 

Should the file names carry the version number as well?  I was planning on this for the zip file but perhaps the other files should be named this way as well (i.e. IniFile_V100.scm).

It's ok with me, I too like naming them like that. Maybe it should be left up to the author, not certain here.

I'm thinking to auto-generate the zip file name from the module name and version via some kind of "Release Module" command, which would make the zip file in a specified folder. 

By the way, AFAIK it is not possible to have two versions of the same module in the module list. When a new module is created it's also assigned a key ID that makes it be unique. If the module with the same key as a module to import is already in the list the editor won't allow importing a new one. It is not therefore, by the by, a good idea to release a brand new module by replacing the source code of the existing one and then exporting it. Those two modules would collide if imported into the same project. So a new module, the "New..." button! Moreover, it means we can't have some kind of a module template by just exporting a dummy one but with examples of version or/and dependencies macros/checkings inside.

Wow!  I didn't know about the unique ID thingy, that's very interesting.   

I asked CJ about the possibility of having a default module and room templates.  He said that there is already this possibility with rooms. You put something like _blank.crm in the game folder and "New Room" uses this file as a template.  He didn't say if or when he would do the same for modules.  At the time I assumed that he would do so eventually, however, in light of what we are doing I think it would be a good idea to specifically request it. What do you think?

Using the same name for the file and the macro is appealing to me for some reason

Oh, hehe that's probably another good reason for using shorter version names.

Except that you have already persuaded me that the longer macro names are better.  :  Appealing as it is, I haven't made as good a case for it as you have for the longer names.   However file names can still include the version number like this IniFile_V200.zip.

Yeah why not, nice trick! As long as there is no need to also create other instances of "IniFile" (i.e. there is no IniFile struct).
This can actually be not revealed to the module user or, on the countrary, clearly said that there is a single exposed IniFile instance to access module's functionality. So, I think, it's up to the developer as the module name can really be used as one likes, I think.

Oh yeah, now I see the flaw.  There is the possibility of name collsions, so I think this is not such a good idea, just using norma global variables are  probably a better idea.   In cases where there is a one on one correspondance between the module and the primary struct (i.e. OO object), I would prefer having the possibity of giving the same name as the struct as I have done in the actual IniFile module.  IMHO, this is more intuitive than giving some other name to the struct.  For this reason I would reject my own idea.  Thanks for enlightening me.

... Which also as well brings us back to the naming conventions, GUIs now...

Well, for exmaple, I'll have a module that uses a GUE as well, so the module dependecies will reflect that, and the GUE shoudl also have some comment in to mention the module, but since the GUE wont really have a lot of script (I'm guessing that it includes only GUI on_click and handler functions)  those will have to go INSIDE one/all of the functions.

Scrop has worked out a scheme where you can check for the presense of a module and flag a compiler error if it's not found.   So I guess you would check for a macro definition in one of the handler functions.  Probably it wouldn't need to be done in all of them since you would only need to generate one error.   

I had a look at the GUI editor and I managed to create the following handler function for a click on the GUI.  Is this more or less an equivalent of "interface_click(...) but for only a single GUI?  If so it would be my inclination to put the module dependency stuff in there, since it's the closest thing to a main function for the GUI.  I guess a good question is should this be the preferred method for GUIs of the type you desciribe?   I don't know the answer really because I haven't had time to play with this yet. 

function gSave_Click(GUI *theGui, MouseButton button) {
  
}

Naming conventions: well, to avoid clashes, sicne the GUE fdunctions will go in a global script they'll need prefixes. And the defualt _Click suffix is probvabl;y a good convention to keep, too.  So far I've been prefixing all my gui object names with "go".

Yeah, that's kind of why I was wondering if having a single handler for each individual GUI (as a convention) would be a good approach.  There would fewer names to worry about.   What do you mean by "GUI Object",  Buttons, Lables, etc or individual GUIs or something else?  Did CJ make it so that you could get to the controls via a path such as gSave.Ok or do we need to do something like gSaveOk for example,  to access the OK button on the SAVE gui? 

No we haven't thought about that but I guess we should consider that before we are done.  Do you have an ideas about what you would like to see?

1. Is there a script command which can open an external file, similar to WinExec in MFC for example. So for example, I could open website when the user clicks a certain button from within the game?

The others have answered your actual question but here are a few asides:

• There are script command that allow you to read and write to external files.
  
  
• There is a RunAGSGame() script command that allows you to open another AGS game.  This is done for example, to do an arcade game within an adventure game kind of thing.
  
  
• AFIK there isn't currently a way of opening a website.  However, you could simulate something like that using my previous two comments.
  
  cheers

This could well be related to using a TTF, where the font can draw upwards whereas a SCI font cannot.

Yeah, I think that's exactly what happened.

Coudl you upload the TTF, please -- t'would be handy for me to check the problem.

I just tried to duplicate the problem using a new game and it seemed to work OK.  However the game I am currently working on has a problem importing it.  The problematic font is in the main game directory.  I have  imported it to slot-4 so now if you open the game and select slot-4 in the fonts tab AGS crahes. 

http://www.gaia-spa.com/project/ags/IniFileGame_V002.zip

If there's anything else that needs to be done and I've forgotten, please do say so.

Just an observation regarding the previous lazy evaluation discussion ... Having a "break" instruction would be helpful in avoiding many of the difficulties previously discussed.   For example ....

// Instead of doing this, which produces a bounds check exception
while ((i<SIZE)&&( (buff!=0))) {
   // do something ....
   i++;
}

// One could do this instead
while (i<SIZE) {
   if (buff==0) break;
   // do something ....
   i++;
}

Setting i=SIZE is not quite adequate because many times it is desireable to retain the value of i (to operate on the next token for example).  The workaround is to use another flag of course; it's just not as clean as break.    Since adding "break" is possibly easier than implementing "lazy eval"and could possibly get done sooner, I thought I would add this little bit to the previous discussion and leave the rest to your good judgement. 

Oh and I liked my Valentime spalsh!!!  Maybe next year AGS could pour me a beer  instead of giving me a picture?  8)  I think this should get a higher priority than that "Make My Game" button everyone always talks about.   

[Documentation]

Documentation

I'm getting inclined that it would become rather involved that way and make updating more difficult. Well, maybe if one will write such module they also have a chance to regard the possibility of including additional sections.

That narrows it down quite a bit I'd say. 

Title
Abstract
Contents
Description
Reference*
Revision History
License

* Any of the following variations of "Reference" are acceptable and probably the best one is your suggestion of "IniFile Reference", where IniFile is the module name of course.

IniFile Reference
Script Reference
Refernece
Module Reference

On another note, Nethros has argeed to help us in this project.  He is good with HTML/CSS etc, so I thought he could help us with the document appearance and other web/html issues.   Since he is comming into the project with a fresh mind he may also be able to clear some of our mental blocks, perhaps help us think of names to call things, and generally give us some feedback on what we have done so far.   Somtimes basic questions from the uninitiated are very revealing and helpful.   So I am  looking forward to his participation.   Scrop, do you know of any HTML docs similar to what we are proposing that we can use as a starting point or example of the kinds of things that will be required?   

Programming Conventions

Or what about uppercasing it? IniFile -> INIFILE. Then again, it can bring confusion considering module's macros in the header have the IniFile_ prefix instead.

No,  no, no.  I was making a joke with the language.  Sorry if the humor didn't translate well.  I didn't mean to imply anything about macro naming or anything.  I just thought it ironic and funny that the mis-spelling made me think of the word "muddle" in the context of the discussion.  I just thought to share my amusement with you. 

This, by the way, prompts me another idea on the module naming convention. What about only having IniFile_VERSION_100 etc. as a module name?

Yeah, your explanation of the issue is quite convincing.  I can envision a situation where a set of dependent modules evolve over time, making this scheme priceless. 

What would you think of just using a shorter version of the name like IniFile_V100. And is there a need to have one that tells what the latest version is? For example "#define IniFile_V000 IniFile_V201", where IniFile_V000  asways has the latest version.

And just to be sure I understand.... All modules would contain definitons of current and all previous release versions of the module.  Dependent modules check for the lowest acceptable versions of required modules.  Is this correct?

Should the file names carry the version number as well?  I was planning on this for the zip file but perhaps the other files should be named this way as well (i.e. IniFile_V100.scm).   Using the same name for the file and the macro is appealing to me for some reason. 

I believe there should be no problems with that as static and global functions are basically the same. It's a pity we can't have static member variables, yeah.

Hmmm, I thought of this work around

// Module Header
struct IniFile_Globals {
   // Global Variables
   int Foo;
   char Bar;

   // Global Functions
   import function FooBar(int foo, char bar);
}
import IniFile_Globals IniFile;

// Module Script 
IniFile_Globals IniFile;
export  IniFile_Globals IniFile;

function IniFile::FooBar(int foo, char bar) {
   this.Foo = foo;
   this.Bar = bar;
}

I am not sure if this actually works or if it's something we should suggest as it's a bit convoluted.   What do you think?   

I too surely do! Hopefully, we'll come up with something that would be useful and easy for anyone to follow while they are writing their modules.

Well, at least they will have a starting point and some guidelines to go by.

Sounds like a good idea to me. Sure, I'll see what I can do.

Great, let me know what you come up with.  I looking forward to the discussions that are soon to follow.

Ok, I better get off the forum so I can get some work done instead of talking about it .  See you tomorrow...

crumpet,

I would like to appologize for my sarcastic remark.  I opened your post thinking I could help you but quickly realized that the lack of details made it absurdly impossible.   Well, it was 2:30AM where I am and I couldn't resist an attempt at some humor, hence my remark.   Anyway welcome to the AGS and have fun....

Cheers

RickJ

I think I know what your problem is.   

Has something changed in the last beta regarding the vertical position of button text?  The text is at the very top edge, touching the button ouline almost.  Perhaps it is just my perception but I could have sworn that previously there was a margin at the top of the button.   Is it my perception or has something changed?

Also don't you think the text should be centered vertically as is currently done horizontally?  I suppose something like that is in the tracker somewhere?   

I also had a crash when importing a particular TTF font file.  Other TTF fonts work just fine.  If there is any interest I can post the TTF file that caused the problem, otherwise I'll just dispatch it to the bit bucket and move on.   Just let me know.   

Cheers

*** Edit ***
Ok, I found out what changed.  When I crashed the editor importing a new TTF font into slot 4, slot 4 then containd the messed up font.  After that AGS crashed whenever I selected that font, so I couldn't import over it.  I ended up having to revert back to the default fonts to get rid of it.   That operation changed the font I was using for the buttons.  So here is the conclusion:  Default font-0 when used on a GUI button ends up touching the top border.   Using an imported TTF Arial 12pt on the button leaves an acceptable margin at the top of the button.  So I wasn't imagining things after all.    I guess you can pretty much disregard most of the above but still let me know if you would like a copy of the TTF that cause the original problem.

10 IP addresses?  How many computers are on your network?

And I'm hoping the final answer isn't "Buy another router."

Yeah, me too because I think I have the same router. 

Anyway, see if you can get the above "whosthere" program to work.  I was reading about it and it seems like it's simple to use and since you presumably have a small network you ought to be able to know if other people are using you access point.    Supposedly the program also allows you see a "Get the F*#k off my network" to any parasites you may find.  Just make sure it's not your mom on the other end.

[Documentation]

Documentation

... Well, except maybe for the abstract section, just in case. ...

At one point I put Title and Abstract in the same section but couldn't tihink of a good name.  I sort of made an artificial distinction because the information they contain is  in a different format.   Currently if a line begins with a title capitalized tokens terminated by a colon, it is interpreted as a form field (i.e. name, value pair).   For example "Author Name: John Smith" would be interpreted as a form field named "Author Name" having a value of "John Smith".  The idea is that subsequently in the document that something like @Author Name@ could be replaced with "John Smith".  I don't know if/how this will be used but it's a feature I would like to include.   

I guess my real point here is that if the document generator is to remain single pass then form fields will need to be defined before they are used.   The file head or Title section seems like a logical place for most of those things to appear.   The Title section can then be rendered from a template that includes only the relevant information (using the @substitute@ mechanism).   Information not relevant to title is then available for substitution through out the document.   Ok, I know that it's a feature that may not get much use but it may be something we will find a use for.

So that's the reason for having Title and Abstract in stead of just one section that includes both informations.

I'm not sure about the name because there could be another section with the same name. ...

Ok, we agree aboout the order and content here.  The author of course can add sub-sections as desired to this section.   

... Anyhow, the purpose of the section is to describe the module structure in details.  ...

Is this like a module overview/description that gives technical theory, philosphy, and details about how the module is constructed?  I originally envisioned this info as a "Introduction" sub-section at the begining of the Reference "API or whatever name we choose" section.  I see your point about making it a seperate section though and the following is probably reason to make it so.

./.. The point here is that if one understood the module structure (from the previous section) there is no need to look there all the time ...

I guess it depends on how big and complex this section ends of being.  I suppose there is no way of knowing in advance.   I can go along with your suggestion I you believe this is best, however, if you are a bit uncertain, consider the possibility rolling it into the Reference section.  Hehe, if so we will have one less name to think of.

I think we are pretty much in agreement about the what should be in the document and it's order and structure.  I think we just need to sort out what names we want to give the three middle sections.   I have marked them with a '*' below just for clarity.

Title
Abstract
Contents
Description *
Structure *2
Reference *3
Revision History
License

If we can think of good names for Structure and Reference then we could keep Description as it is.  Of course the converse is also true so I guess the best thing is to brainstorm (i.e. make a list of possibilities and then choose after we have a big list).  Ok, I'll start it off and here is my list...

DESCRIPTION section's possible names

• Description
  
• Tutorial
  
• Using Module
  
• Using @Module Name@
  
• Operation
  
  STRUCTURE section's possible names
  
• Description
  
• Structure
  
• Module Structure
  
• @Module Name@ Structure
  
• Theory of Operation 
  
• Operation
  
• @Module Name@  Operation
  
• @Module Name@  Internals
  
  REFERENCE section's possible names
  
• Reference
  
• Module API
  
• Scripting
  
• @Module Name@ API
  
• @Module Name@ Reference
  
• @Module Name@ Scripting
  
• Scripting Reference
  
• Scripting API
  
  It would be good to get opinions and ideas of others about the section names.  Let me know what everyone thinks and don't hesitate to  make suggestions.
  
  Programming Conventions
  

  
  So the question is, should it just be an underscore character or maybe a longer prefix like "MUDULE_" or something simiar?
  

  Either one works for me, pick one.   
  
  Hehe, you mispelled MUDULE, which sounds/looks a lot like muddle, which is what we are trying to avoid.   
  
  

  
  A bit clumsy, I agree, but that's the only way out so far ...
  

  So should we recommend that or recommend doing the version check at runtime?  Perhaps at runtime is best because we could also do the warning thing then as well.  I guess the warning could be surpressed when DEBUG mode is disabled.
  
  

  
  Well, that's another issue. The question is, should we made all global functions static?
  

  Ok, I understand.  That's actually a good idea because from the outside looking in everything looks consistent.  Why should some functions use an underscore and others use a dot?  It's too bad member variables can't be static.  That would make everything very consistent.  Is there any situation where this wouldn't work? 
  
  

  I think enum type name is only used by the autocompleter to list related enum values. Or do you mean something else? ...
  
  Unfortunetly, no. They all must be unique. I think it's a good idea to use prefix for module enums that in the header
  

  I meant to ask is there a difference in how enum names and values are defined (i.e. naming convention).  So you seem tot give the answer in your reply to my next question as follows:
  
• Enum Names - IniFile_EnumName
  
• Enum Values - IniFile_eEnumValue
  
  

  I agree on them. Well, maybe there could be exceptions for the internal implementation of the module. One may also want to use variable names like "loopCounter" or bFlag (with b have a meaning of "bool") etc.
  

  You mean have an optional lowercase prefix for "static variables" and "application functions"?  Yeah, I used that for the original Blue Gui to uniquely identify it from other code.  I guess I dropped it in favor of usingthe full module name for that purpose.  But I can see the usefulness of allowing such a prefix internally, especially for larger modules and for authors coming from a MS/VB world where variable names are commonly prepended with lowercase versions of the associated data type.   So, I agree we should include this option in the convention.
  
  

  Yeah, sure there is no need to clutter up the source code with prefixes since they are not required there.
  

  Ok, agree.  We should remember to make a clear statment about this, otherwise well meaning authors may fall into this habit out of FUD.
  
  

  Think, yeah, I'll begin with module dependency stuff and then after it will be cleared up we can continue on other conventions. Module naming seems like the only difficult issue so far. Smiley Adding/editing document in turns seems to be a good idea. I also hope others will suppose ideas as well.
  

  That's great.  Thanks for helping, it's a real pleasure working with you.  I appreciate your comments and input to this process.  I always worry about missing or misstating something that is obvious. 
  
  

  Sorry I've missed something because I'd written pretty much yesterday but was unlucky (or silly...) to accidently close the window thus wipping everthing out I had on the topic.
  

  Hehe, I'm sorry but you made me laugh out loud because I too have done this too many times and I am too emarassed to say so.   It's scarry how like minded we are .
  
  Btw, do you remember that system plugin you did for me a while back?  What would you think of adding 7-zip or somthing similar to it?   I am thinking of making an app that, in addition to generating the document,  will collect the module.scm, document(s), and other releated files into a zip file named something like ModuleNameV100.zip.   
  
  I'm cleaning up the parser functions right now.   When I am done with that I will post a version for you to see what I am doing.   Then I will start work on document rendering.   I have an idea to use INI config files to specify the document  structure, so that the system will be flexible.  If things don't get too complicated I'll  implement it this way.   
  
  I look forward to hearing from you soon, providing you remember to hit the post button this time 

RickJ: Disable the wireless portion? How would I do that, and could I use the wireless feature at all? That's why I got it after all.

You can disable it from the setup page and no you wouldn't be able to do wireless stuff if it were disabled.  But doing so may have shed some light on the problem so that a suitable soultion could be found. 

Dump a log? Packet sniffer? You're disgusting, RickJ

Hehe... well then just to make your stomach turn ... here are a couple of sniffers I found.  Try them out and let us know which one you like best.  :

• http://www.ethereal.com/
  
• http://www.snort.org/
  
• http://support.it-mate.co.uk/?mode=Products&p=whosthere
  
  Here is a larger list
  
• http://www.insecure.org/tools.html
  
• http://lists.gpick.com/pages/Packet_Sniffing.htm
  
  And here is a discussion about restricting wireless access to your computers
  
• http://slashdot.org/article.pl?sid=05/01/17/1832214&from=rss
  
  *** Edit ***  misspelled  URL,