VEXcode for experts

When reading the forum over the past several days, I’ve noticed some confusion over the release of VEXcode 1.0 (and 1.0.1) and what has changed from the August 0.9 version. I want to try and clarify a few things and comment on a few rumors that seem to have started. I’ll also try and add some tips for the advanced user over the next few days,

Features were removed that were available in 0.9

mostly not true, all functionality that was available in the 0.9 version is available in 1.0. The exception is the competition checkbox that used to be present when creating a new project, the preferred way to do this now is to open the competition project example.

When you build a project in VEXcode, your source code is compiled and then linked against a special library that contains all of the VEX classes and functions that do things like making motors spin, we generally refer to this as the SDK, or software development kit, that VEXcode uses. Nothing was removed from the SDK for 1.0, all code (again, one minor exception, the drivetrain class changed ever so slightly) that was written in 0.9 will build in 1.0.

Should I update my 0.9 project.

My opinion, if you were happy with 0.9 and had created a project that was non-trivial, then don’t upgrade. The new graphical robot config will be disabled, but you have probably mastered creating instances of motors already.

I upgraded and VEXcode commented out all of my code.

If you upgraded, VEXcode will have commented out all of your code in main.cpp, the primary reason for doing this was to allow the graphical robot config panel to be used, instances of Brain and Controller in main.cpp would conflict with new instances created in robot-config.cpp and the project would not have built. The easiest way to revert this if you just upgraded is to use “undo” (CTRL-Z) and that commenting will be reverted, however, that step only works if you have just upgraded and not saved anything. If you do uncomment, remove the instance of vex::brain near the top of main.cpp as this will have been added to robot-config.cpp. If you take this approach then it’s probably best to avoid using graphical config, it is hard to have both ways of creating devices play nice together, so you need to choose, either stick to graphical or the way we were doing it in 0.9 and all the VEXcode previews unless you understand the implications of mixing both techniques.

Upgrading changes the SDK
The SDK used will be the same whether you upgraded your project or not. The upgrade process added the two robot-config files and enables graphical robot config, it does not have any impact on the code itself beyond commenting out the code in main.cpp as discussed above.

What are all these expert mode.

The expert modes only affect two areas. How the intellisense autocomplete works, and in 1.0.1, is graphical robot config available.

In both modes all functionality of the SDK is available.

VEXcode uses something called a language server to analyze errors in your code as you type, it’s this language server that creating the red squiggly lines in the code when you have an error. The language server is also used to suggest function and class names as you type, however, the language server will suggest things based on its understanding of all the source files, the vex SDK and also other standard header files that are needed to build a program. Although this is the standard approach used by professional programming tools, it can be confusing for beginners. To help with this, Robomatter created a simpler autocomplete tool similar to that which had been used in VCS. The “enable expert autocomplete” checkbox is used to select between these two methods, however, it has no impact on the complexity of the code you choose to write, your project can use all of the VEX SDK functionality in both cases.

Robot Config.
The new mode added in 1.0.1 was to allow disabling of graphical config and allow editing of the default configuration files robot-config.cpp and robot-config.h. The reason that these files are read only when graphical is used is that any code added by the programmer would be lost when the graphical robot configuration is changed. To allow editing, graphical config must be disabled. If you add anything to robot-config.cpp and then go back and use graphical, those changes will be lost.

What is vexcodeInit
some of the things you can create in graphical robot config need some initialization code to be run. This includes , for example, the Controller if you have assigned buttons to run motors and the drivetrain if a gyro is being used. vexcodeInit is not a replacement for the old robotc pre-auton function, if you need code to be run at the beginning of your program place it in your own initialization function or in main after the vexcodeInit funtion.

VEXcode does not allow multiple source files
completely untrue, you can have many source files. You can also have multiple projects open at the same time

I have to use graphical config to configure a vision sensor
Not true, you can still create vision header files and configure in the same way as 0.9


Hopefully this will help keep down all the confusion from people upgrading


I’m wondering if i made a new file that had functions would work. So all my void functions stay in one file and all the actual execution using the void functions stays in another file. Would that work? And could that file import from the motor setup file?

Here’s an example, the files in the project look like this.

I created two new files, one in the src folder called myfunctions.cpp and one in the include folder called myfunctions.h (of course they can have any appropriate and meaningful names)

myfunctions.cpp just has one function that looks like this (just as an example)

// to allow access to SDK classes and class member functions
#include "vex.h"
using namespace vex;

// add two numbers and return the result
addtwonumbers( int a, int b ) {
    int result = a + b;

    return result;

vexfunctions.h has the function prototype, that lets the compiler know the functions name and what parameters it accepts but does not define the body of the function.

// declare the function prototype here so
// the compiler will understand it when used
// in other source files
int   addtwonumbers( int a, int b );

Then to use the function in main.cpp we could either include my functions,h in that file or somewhere like vex.h

#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "v5.h"
#include "v5_vcs.h"

#include "robot-config.h"

#include "myfunctions.h"

now we can call that function from main.cpp (or any other source file) and the compiler will not show any errors.

#include "vex.h"

using namespace vex;

int main() {
  // Initializing Robot Configuration. DO NOT REMOVE!
  Brain.Screen.print( "2 + 3 = %d", addtwonumbers(2,3) );

project attached (9.4 KB)


will running motors in the functions work or will you have to #include config in the function files?
or does using namespace vex and #include “vex.h” already do that?

Anything defined by graphical config would be available to use

including vex.h allows that.

“using namespace vex” allows the use of classes and globals in the vex namespace ( a namespace is used to keep the classes and variables we use separate from those created by others) without need to prefix with “vex::”

so without “using namespace vex” you would have to write

Motor1.spin( vex::forward );

adding that line in allows

Motor1.spin( forward );

I also noticed that now new projects come with 2 pre-made functions, one of which was waitUntil. I assume this is comparable to waitUntil from RobotC, based on looking at what is in the function. Can you confirm that?

Also, I tried copying that function into PROS and it didn’t work. Does VEXcode have anything that makes it work specifically for VEXcode, or is it just generic c++?

waitUntil is a macro, look in vex.h

#define waitUntil(condition)  \
  do {               \
    wait(5, msec);   \
  } while (!(condition))

it was added to match functionality available in VEXcode blocks

wait is a real function, it’s a wrapper for task::sleep, again to match functionality in VEXcode blocks to help students moving from blocks to text.

you could easily duplicate this functionality in PROS or RMS.


is there a reason for 5 msec rather than 1?

I’d assume it would be to save processing power for other tasks. Repeating it 1000 times a second leaves little room for other things to compute.


James, what is the significance of the slash marks in waitUntil? I noticed if they were removed the “do” and “while” showed up as an error.
Also, how do you open two files at once? Thanks.

That is the reason, but in the case of the v5 it usually doesn’t apply since you really aren’t running much, and the important task like motors and communication are handled on other cpu’s. It is probably the reason and good practice but not too significant.

They are required for a multi line macro (#define). Since it isn’t terminated with a semicolon it ends when there is a new line, unless there is a back slash.


The back slash is line continuation, it lets you define a macro over several lines as opposed to having to write it like this.

#define waitUntil(condition) do { wait(5, msec); } while (!(condition))

Two files ? If you mean two projects then use “new window” and then in the new window open the second project. If you meant two files, you should just be able to click on any file in the directory tree and it will open in a new tab.


Thanks :-). Owe you a chocolate macnut.


Example code for the motor group and drivetrain classes is here.

1 Like

I saw this comment in our feedback system

task::sleep was eliminated, causing a lot of pain

I want to reaffirm that nothing has been removed from the SDK with the VEXcode text 1.0 release.


I understand having multiple source files open at the same time, but It was also stated that “You can have multiple projects open at the same time”. When I try to open a new project, it closes the first project. How do you have multiple projects open at the same time? Do you just do multiple windows or can you do them all in the same window?

1 Like

One project per window. So yes, open up a new window and then open the project.

1 Like

can we use vex::event or mevent ?

you can.

I’ve never really talked or explained events much. We use them internally for things like button presses using function on other classes, but you can create you own events and choose when to use them. For programmers coming from blocks, this should be quite familiar, although many of the places they are used in blocks should really be using function calls instead.

if you have a function like this.

eventHandlerA() {
    static int event_count = 0;
    Brain.Screen.printAt( 10, 90, "Event A %d", event_count++ );

you can register that as an event in this way

vex::event myUserEvent( eventHandlerA );

and then cause the callback to run using the broadcast function.


more than one event handler can be assigned to a single event, see the demo at the end of the post for that.

An “mevent” is a little different, it was designed for use in a polled environment where using the pressing() method may not work well, either because you missed the button being pushed or because you used it in a loop and were only interested in the fact that the button was pushed and didn’t want to add the additional logic to filter out the fact it may stay in that state for a while. They were intended for use by the blocks part of VCS, but in fact were never used in that way.

It makes a good replacement if you find yourself doing this a lot.

        if( Controller1.ButtonA.pressing() ) {
          while( Controller1.ButtonA.pressing() )
          // do something

or this

        static int isPressed = 0;
        if( Controller1.ButtonA.pressing() && !isPressed ) {
          isPressed = true;  
          // do something
        if( !Controller1.ButtonA.pressing() ){
          isPressed = false;

Both of those can be replaced by

        if( Controller1.ButtonA.PRESSED ) {
          // do something

Here’s a small demo using both ideas, they happen to be combined in this demo but don’t have to be.

/*                                                                            */
/*    Module:       main.cpp                                                  */
/*    Author:       james                                                     */
/*    Created:      Mon Feb 03 2020                                           */
/*    Description:  V5 project                                                */
/*                                                                            */
#include "vex.h"

using namespace vex;

// A global instance of vex::brain used for printing to the V5 brain screen
vex::brain       Brain;

// define your global instances of motors and other devices here
vex::controller  Controller1;

eventHandlerA() {
    static int event_count = 0;
    Brain.Screen.printAt( 10, 90, "Event A %d", event_count++ );

eventHandlerB() {
    static int event_count = 0;
    Brain.Screen.printAt( 10,110, "Event B %d", event_count++ );

int main() {
    int count = 0;
    // create a user event
    vex::event myUserEvent( eventHandlerA );
    // add second callback to the same event
    myUserEvent( eventHandlerB );

    while(1) {
        Brain.Screen.printAt( 10, 50, "Hello V5 %d", count++ );
        // this uses an mevent, it will act like a one shot
        // that is, it will only happen once when the button is pressed
        if( Controller1.ButtonA.PRESSED ) {
          // trigger the other event handlers, both callbacks will run

        // Allow other tasks to run