Comments: differences between semicolon, C-style and REM

[Moonbeam]

Hi,

 

I see that the comments done with a semicolon or C-Style are not automatically in green color. Is this a wanted feature?

 

Thanks in advance for the reply!

[+Random Terrain]

Hi,

 

I see that the comments done with a semicolon or C-Style are not automatically in green color. Is this a wanted feature?

 

Thanks in advance for the reply!

 

If you are talking about using Visual batari Basic, click on the Settings tab where you can change the colors and edit the dictionary.

[Moonbeam]

Oh... sorry, I talked about Visual bB

"Enable color coding" is checked and "Comments" is in green color. What could I do with the dictionary so that semicolon and C-style comments appear in green?

[jwierer]

What build are you using? Mine does color code these as green comments already.

[Moonbeam]

It's build 554. Well, after a few attempts, every type of comment I write is black. And when quit Visual bB and open it again, rem and semicolon comments appear green. C-style comments remain black.

Edited August 15, 2014 by Moonbeam

[+Random Terrain]

jwierer might want to put the latest version in the VbB thread since there have been some changes since the last update.

[jwierer]

There is a more recent build in my blog. See post #1

[Moonbeam]

I copied the files from the build 566 in my VisualBatariBASIC directory and then replaced the older files.

 

The comments are maybe ok now but the IDE is not stable anymore and buggs when I hit "return" key, after I write "*/" at the end of a C-style comment. Am I the only one with this problem or must the new files be installed in another way?

Edited August 16, 2014 by Moonbeam

[+Random Terrain]

I copied the files from the build 566 in my VisualBatariBASIC directory and then replaced the older files.

 

The comments are maybe ok now but the IDE is not stable anymore and buggs when I hit "return" key, after I write "*/" at the end of a C-style comment. Am I the only one with this problem or must the new files be installed in another way?

I'm using build 568 and don't seem to have that problem. Various changes have been made since his blog post in 2012, but you may be having a problem for another reason. When I download a new version of VbB an its accompanying sound library (you can't mix and match), I keep it in a new folder. I don't replace anything. The only thing I do is copy the bookmarks file (visualvb.mdb) from the previous VbB folder and paste it into the new VbB folder so I won't lose my bookmarks.

 

In case you're interested, I name my VbB folders using the date and military time, just like I do with versions of my programs. Example: Visual_bB_2014y_06m_21d_1037t

[+iesposta]

I know one type of comment is kept through compile and is in the asm code, and another type of comment is thrown away.

 

I think REM stays in the compiled .asm, and ";" disappears.

I don't know about */

[Moonbeam]

I'm using build 568 and don't seem to have that problem. Various changes have been made since his blog post in 2012, but you may be having a problem for another reason. When I download a new version of VbB an its accompanying sound library (you can't mix and match), I keep it in a new folder. I don't replace anything. The only thing I do is copy the bookmarks file (visualvb.mdb) from the previous VbB folder and paste it into the new VbB folder so I won't lose my bookmarks.

 

In case you're interested, I name my VbB folders using the date and military time, just like I do with versions of my programs. Example: Visual_bB_2014y_06m_21d_1037t

 

Thanks a lot for your help! I had also got the reliant sound library.

 

For me, the installation of bB & VbB is such a mess... Is it possible to find the build 568 somewhere? Or is build 566 the more recent one available?

I think I'm going to try to install bB & VdB from scratch again :-/

[+Random Terrain]

Thanks a lot for your help! I had also got the reliant sound library.

 

For me, the installation of bB & VbB is such a mess... Is it possible to find the build 568 somewhere? Or is build 566 the more recent one available?

I think I'm going to try to install bB & VdB from scratch again :-/

Jwierer sends me new versions for testing and doesn't want to burden people with constant updates of VbB, but I think that a couple of times a year wouldn't be too much of a burden on people. He might want to go ahead and post build 568 in the official VbB thread instead of sending people to his blog for an older version that is around 2 years old.

[jwierer]

I just haven't had a free weekend to post a clean build. One of these days I'll get around to it.

 

-Jeff

[Moonbeam]

Actually what makes VbB bug (it freezes) is: when I hit "return" key, after I write "*/" at the end of a C-style comment AND "Enable Syntax Checking" is checked.

 

I use:

- VbB 1.0 build 566 with its corresponding sound lib, installed in C:\Atari2600\VisualBatariBASIC

- batari BASIC 1.1 from batari_basic_1.1beta.zip, installed in C:\Atari2600\batariBASIC

 

The problem does not occur with Build 554, but the syntax checking became extremely slow (it was not the case a few days ago).

Edited August 17, 2014 by Moonbeam

[+Random Terrain]

Actually what makes VbB bug (it freezes) is: when I hit "return" key, after I write "*/" at the end of a C-style comment AND "Enable Syntax Checking" is checked.

 

I use:

- VbB 1.0 build 566 with its corresponding sound lib, installed in C:\Atari2600\VisualBatariBASIC

- batari BASIC 1.1 from batari_basic_1.1beta.zip, installed in C:\Atari2600\batariBASIC

 

The problem does not occur with Build 554, but the syntax checking became extremely slow (it was not the case a few days ago).

Is your program really, really, really long? When I'm working with a program that has a lot of code, I have to turn off syntax checking.

 

Also, what happens when you copy and paste this into your program:

 

   /* comment #1 */


   /* comment #2
   */


   /*
   comment #3
   and some more of #3
   */

[Moonbeam]

Is your program really, really, really long? When I'm working with a program that has a lot of code, I have to turn off syntax checking.

 

Also, what happens when you copy and paste this into your program:

 

   /* comment #1 */


   /* comment #2
   */


   /*
   comment #3
   and some more of #3
   */

Well my code is not that long. Maybe 600 lines, I don't know... But I started thinking that this could be the cause of the problem... Thanks for telling me to deactivate syntax checking with quite a long program

When I copy and paste the 3 comments you indicated, nothing special happens, whether syntax checking is turned off or on.

 

I still notice problems with the color of some comments. I guess it's probably because they include some special keywords, but it's disturbing.

For instance, the following comment appears in 4 colors, exactly like this: /* Byte{0}: is set to 1 when..., in order to indicate to... */

 

Edited August 19, 2014 by Moonbeam

[jwierer]

The color coding is problematic. I wrote it and I generally turn it off. The .NET Framework doesn't really have an intrinsic control that lends itself to the task so it's very limiting.

 

-Jeff

[+Gemintronic]

I really don't have a problem doubling down on styles.

 

rem /** This works just fine for me! **/

 

For me it makes the comments really stand out.