Restore to previous working flowcode

[WingNut]

It wouldnt be the first time I'd spent a lot of time resolving a problem in flowcode and then mucked it up when I had a great idea after a few beers only to get up the following day to find I'd edited something out that I really needed and couldn't figure out what I'd messed up for a while. A nice feature would be something like windows restore to a previous working version. Might already be there.
The solution is not "dont drink beer"
As a flowcode gets developed it can be quite complex and if you arent at it everyday its easy to forget things. Ive used multiple saves with different names but that gets cumbersome

It would also be great if it could output a basic diagram showing the various connections so you have something to reference when you make up the prototype

I know its all a big ask but you guys are def very good

[Steve-Matrix]

Good ideas there - I'll try to think how to improve things for future versions. Knowing what the previous working version is could be tricky (unless it's simply "it compiles without error"). You could manually make some 'permanent' backups before undertaking major changes to your project - especially when beer is a factor .

[mnfisher]

Git integration - please....

[kersing]

Hi Steve,

Please consider integration with something like git. That would allow going back and forth and allow the user to enter some change information on commit. I’m now using it manually but having version control integrated would make using it as lot more convenient.

[Steve-Matrix]

Thanks for the requests for integration with version-control systems such as Git.

Obviously, we use version-control heavily in the development of Flowcode, both with the development of the main executable itself and also the maintenance of ancillary files such as components, chip definitions, etc. It's a fundamental and essential part of our development processes. However, we tend to use file-system integration of these tools (e.g. Tortoise) rather than integration directly within our development tools (such as Visual Studio). This works well for us as it gives us more control over how we manage our codebase.

My worry with developing integration with Git within Flowcode is that it would limit the user's choice in terms of the system used and the features we present within Flowcode's UI. It would also be one more aspect of the Flowcode codebase we would need to create and maintain.

As an alternative, how about something more generic like an "external tools" menu where any number of external files can be launched from a user-customisable menu, with user-defined command-line parameters which can include substitution strings such as "projectdir", etc? Many software tools have this feature (e.g. Visual Studio), and it should allow a user of Flowcode to add any version control features they wish.

[kersing]

Hi Steve,

Being able to add items to a menu would work fine if they are executed (or can parameterized to do so) in the context/folder where the flowchart lives. Using it from explorer with Tortoise like I’m doing now is inconvenient as it requires browsing to the project folder all the time (or keeping the file explorer open which gets closed far too often when not paying attention).

[mnfisher]

I can see it would be a fair bit of work - how many features of git (or svn etc) should be supported? Branches / forks etc?

But I would be happy if one 'system' was opted for and supported well (I tend to use git so it gets my vote) - there are other alternatives (creating a use definable number of 'backup' versions which could work) - but unless FC can be modified to use a temporary file for compilation rather than a save - I can see this approach causing problems too... There is always the problem of at what 'point' is the new version created (which applies to version control software too)

Martin

[Steve-Matrix]

I think a generic 'tools' function should be ok. The apps where I've seen a customisable tools menu generally have 4 options for each tool:

• Title for the menu item for the command
• The actual command (i.e. exe, batch file or dos command)
• A list of parameters for the command
• An initial working folder for the command

This should allow for pretty much any facility to be created - from simply copying and renaming the source file to exposing a full set of commands for your favourite version-control system.