VEXcode V5 Text Preview


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.

1 Like

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;

Personally, I think it is better practice to not use the using keyword.

Yeah, including entire namespaces with using isn’t the best habit to get into, but in the greater realm of c++ sins it’s not that bad. Still, I try to avoid it where possible.

Most of the (non-vex) c++ programs I write nowadays contain the following near the top:

using std::cout;
using std::endl;
using std::cerr;

I find that those are the three things I use most often in the std namespace, so this saves me a fair bit of typing without most of the potential namespace pollution issues.

Perhaps it would be a better practice to do something similar with some of the most commonly used names in the vex namespace, such as directionType and velocityUnits (and/or whatever other names are most common – I don’t have v5 parts in hand so haven’t written much vex c++).

What exactly will be the fate of VCS? Will the C++ functionality be removed from it in favor of VC? Will modkit ever receive proper competition support? Or will it continue to exist in parallel with VC? Or will none of this happen and is VCS just dead?

In the future, can some kind of communication actually happen with the community regarding these things? It’s presumably been 6 months at least since VC started development and we have had exactly zero information that this was happening until now.

And if possible, can these kind of things be better planned in the future? VCS development presumably happened before the season began, then was abandoned at the start of the season, and only now that the season is over a viable replacement is presented. Had there not been third parties willing to pick up the slack during the season, teams would have been in trouble. IMO getting VCS (especially modkit) to a usable state should have been a priority before building something completely new. Development could have then happened primarily during the post-season and summer and it could have been released in the fall ready for teams to use.


Honestly, I kind if regret releasing NotVCS, since the VCS developers may have seen that as “the community will take care of vcs not being good, so we’ll focus on other things”