VEXcode V5 Text Preview


We don’t currently have Linux on the road map. But we will keep that in mind for future releases.


Has the SDK in this been updated to properly support pwm control of motors?


yes, if you mean open loop voltage control.
This has all the latest and greatest features in the SDK that I’ve been saying we would release.


Is there/will there be a public changelog available for SDK versions?



That is a great question. The team actually looked into doing a VS Code extension at first. But there were a lot of limiting factors in taking that route. Using Monaco will allow us the most of the nice features of VS Code and still give us a lot of freedom in our design.


For the final version, also please allow us to change the install directory, some of us have programs on separate disks from our OS.



We have that feature on our list. We will get that worked in.


I see a terminal there.

Will we ever be able to do command line based uploading?


Looks pretty good; while I’ll probably stick with PROS for the time being as it’s open source and runs on Linux, it’s a great step forwards from VCS. One suggestion I have it to remove (or make far smaller) the minimum window width as right now, it can’t even go half screen on my machine.



The terminal tab in VEXcode is for logs coming from your user program via “printf” and “cout<<”. It does not allow for input of any kind in its’ current state.

I’ve noticed this too, and althouth I use PROS and don’t intend to change, this would be high on my list of reasons not to if I ever decided to. It’s really annoying when you’re trying to have two things open (such as a web browser) without switching constantly.

I agree this would be an awesome thing now that the SDK version is publically shown in the editor instead of being a sort of hush-hush thing.

Lil’ bit of advice for anyone who wants it: If you manage to fluff up the SDK somehow and need to force an update, if you delete [INSTALL LOCATION]/sdk/manifest.json VEXcode will assume a new version is available and overwrite your existing version. Could be handy for smth, idk.


Here’s another thing that I find to be a problem, though others might not: Because of the way NotVCS works, in the past I would always #include all of the other .cpp files into main.cpp. Because of the way I was doing this, it didn’t build any files other than a big combined main.o. Will it be possible to have an option to preprocess and build main rather than building every file separately and #include-ing headers for each?

This is a huge improvement over VCS in most ways, but I plan to stick to NotVCS until porting my code to this new IDE becomes easier.

I would recommend including header files anyways as including cpp files directly is quite a bad habit.

1 Like

I would like to adapt to this type of programming eventually, but I didn’t have a choice, since there’s only so much a pytohn script can do to add multi file support to VCS. Of course this new way of doing things will compile faster, which is nice, but I want the option to be able to use bad coding practices.

So once a project is created, you have full control over the build if you want to edit the makefile (and makefile support files). We have set this up to be straightforward for simple projects, source code in the “src” folder etc. but if you want to use a different project structure you can do that.


New/updated versions of the sdk are installed in a different location to the application. We include the most current base sdk with the application but if a newer versions is available and installed we would use that instead. Deleting the manifest file will just confuse VEXcode.


Oh haha. It did indeed die horribly when I tried renaming sdk/ to sd_k/ to produce the same effect. I didn’t consider the fact that it might store multiple copies of the SDK :smiley:.
Are there any plans for down the line to eventually release the SDK documentation publically to allow for people who want to directly use it without wrapping it in a nicer wrapper without the fun that comes from using an undocumented library?


how can there even be a decision to be made with regards to including a blocked based version for IQ. Just adapt ROBOTC graphical like it is now. It is severely limiting your growth due to many school districts are app (mine included), and you are setting them up to leave because they have no curriculum that they can utilize like your Windows based “introduction to programming vex IQ”. The Modkit workbook is a joke, and they (apple users) are left with no guide. You already have the tracks, which are great, but again not tailored to Mac IOS. Though nit simple im sure, the template for transition is there. I think it is imparitive to your future success that this be made a top priority.

1 Like


I am in 100% agreement with you. My answer was directed at incorporating IQ into the VEXcode app. That decision has not been made as of yet. But that does not mean we are leaving IQ behind. When we talk about improving the VEX coding experience we are talking about all of VEX, including IQ. This is just one step in that direction. We are working hard to make the V5 and IQ programming experience better on all major platforms (Win,Mac,ChromeOS,IOS,Android) and we will announce more as timeline solidify.


I tried out the VEXcode and I am impressed. I did find a minor hiccup using the competition template - it doesn’t have the namespace declared in the robot-config.h file.

void usercontrol( void ) {
  while (1) {
    //without namespace you need to use the vex:: prefix (namespace).
    motor1.spin(vex::directionType::fwd,50, vex::velocityUnits::pct); 
    //with namespace included...
    motor2.spin(directionType::fwd,50, velocityUnits::pct);           


Simply add the following to the robot-config.h file:

using namespace vex;
1 Like