Hi,

There are some planned improvements to make arduino library creation/publish easier. 

The structure of an arduino library is shown when you use the create local project library command. Visual micro creates the correct library structure so you can use windows explorer to copy/deploy a library for sharing. I accept that if you want to share and edit a library at the same time then this method isn't the best solution. However it allows a library to be debugged.

Using the format of an Arduino library means you can #include "libheader.h" without having to specify a folder location.

Creating a new arduino project as a library will not work. Visual micro expects and arduino project to be an arduino project and not just a normal c++ project which is what a library would be.

The shared project system is the easiest way to break code down into chunks. What did you find complicated about it? If you create a visual studio shared project and add a file called "mycode.h" then you can simply #include "mycode.h" in any arduino project that has a Reference to the shared project.

The plan is to provide a property on the shared projects that allows you to switch between "Compile as sketch code" and "Compile as library". This would then make creating a shared library in any location available to any project.

Probably a food idea to bear in mind that a library doesn't have a setup or loop (main) etc. so would not built in isolation.

I don't know if you have used "vMicro>toggle hidden files". This will allow you to see/edit library sources from the normal arduino library lications.

The idea is to stay as close to arduino as possible while opening up more and more additional options for users. If we stray too far then we end up having to support peoples code and people learning new ways of working,  which would be too time consuming and expensive for a mainly free product. That's where a make file would be better

Okay here are some answers

1)
The create library option gives you a normal sketch with one example local library below it. It's an example to get users up and running.

2)
There is a heck of a lot in the free version of visual micro and it takes a considerable amount of time to produce and support. The question is not if more functionality should be available for users but if existing functionality should no longer be free.


There is no doubt that via user feedback the product will continue to expand. 

Considering that no other products have half of what is in visual micro and that so much is free, it is disappointing that people do not feel they can appreciate what is there and contribute to help it grow.

Hi,

I am really sorry I made you feel like that. Not the intention at all and your post helps towards deciding on priorities.

It's a very good topic to discuss how it can be implemented. The product has to cater for many types of users. Some experienced with C# and new to micro-controllers, some with C++ and new to arduino, some new to all code and some experienced in all areas.

The main goal that allows support to remain at a minimum and keep the product free or at very low price. Unfortunately it's very difficult for new arduino users to know what is standard arduino and what is "extra" tools provided by visual micro. 

It gets very confusing if users believe some extra feature is standard arduino and then attempt to seek assistance in, for example, the arduino forum.

You will be amazed at how confused users can become. You might ask that you could edit all libraries more obviously in the software and then to edit the core of the board which is also located in a different location. Reasonable requests but many new users would think this is normal for arduino, edit libs and core, then wonder why other projects have broken.

Arduino libraries are very simple so using windows explorer isn't a huge difference from having a publish facility yet it would require an auto backup/versioning consideration that would be quite time consuming to design when there are so many other more useful features that could be created in the same time frame.

During the past 18 months arduino has made huge changes, for the better, to the build process. It has only recently established hence the last release focused on build times/cache.

Hopefully we can now get back to more fun things such as managing project properties in a way that more easily allows teams to share via source control and making editing or creating of libraries and new cores easier.

The shared projects are an interesting route. Currently the code from shared projects is simply merged with project code. This is useful for some users because that means the shared code can interact with the project code, where as arduino libraries have no connection to the project code.

The reason why I say shared projects are interesting is because the plan for next release is to provide a property on each shared project that allows you to specify if the code should be compiled as project code or as a library. This will give editable libraries from any location n a pc.

As a windows developer you are used to references to windows .dll files etc. The closes thing to that for the gcc c++ language is .o and .a files however they are supported by arduino as files you can "include" in a project and would also not work well for intellisense purposes.

Hope this makes sense, we really recommend using the arduino ide for a short time to understand what arduino is so you can more easily see where we are and suggest where to go next 

That's really excellent and useful. Thanks very much!

...

Some things that might help sometimes....

I forgot to mention the "vMicro>Toggle Hidden Files". 

If there is a src\_micro-api then any #included libraries are automatically copied and created as local project libraries

If there is not a src\_micro-api then all the core and #included library sources are automatically created as short cuts under a filter called src\_micro-api-readonly

If "toggle hidden files" is in "short cut mode" the core and the library sources are automatically switched when a different board is selected. 

The core and library code short cuts that appear under the "src\_micro-api-readonly" folder continue to be compiled as normal. Therefore they can be altered but will affect all projects and cause longer compile times because changing core causes a recompile.

Thanks again