VL.WorkflowFoundation

you always need a state machine, some just don’t know it. :)

to understand why i picked this and invested time into it, here is a bit of story behind it:
since the old qfsm days, it is clear that you should start most of your projects with a state machine. it solves high-level application logic and is better to understand and design as doing the same in a vvvv/vl patch.

since the early days of vl we are talking about ways of integrating a state machine into the vl workflow and i was looking now and then into other tools like ventuz, unity etc. to see what they have come up with. one day i watched this video a bit and saw the concept of state machine hierarchies and all the events like enter, leave etc., which made total sense and i wanted to have that for the future vl state machine workflow.

as said in the original post, i was looking into it recently again and saw this funny workflow thing which exactly has all those features (and much more) and is tested since years. pulling it out of everyone’s pc and making a glue for vl looked easy enough to try it. and it was literally just 3 evenings of coding. compare that to developing a whole system from scratch, it would take weeks and would need testing. this is available now!

it was not trying to re-inventing it, just gluing it to vl until there is something better/more appealing. till then this is a working solution with minimal effort, problem solved for now -> more time for other things. so it was a quite pragmatic decision and i certainly don’t want to proclaim this as the final solution, just good enough for now.

since the interface to vl is very slim, you could implement the same interface @u7angel. then it can be replaced later and the same nodes would still work, just with another ui/editor. so please go ahead whenever you have time. would love to see a better looking state machine in the near future.

@tonfilm
this is absolutely understandable and great you worked on that. my criticism was about communication channels. i‘m really interested in a discussion like that and i‘m an avid reader of the forum and riot. but still this question slipped through.

there are just too many ways for discussions i guess.

anyway, back to the topic and something i like to add. are you planing to introduce some interface for VL to add additional editors to the UI. so rather placing a editor node somewhere in the patch, with view/close bangs but integrating better in VL aka dropdown menu, dockable window etc.

when we talk about something like workflow foundation, it would be nice to have something like that.

its not easy to catch up in the chat sometimes and not all topics get a forums thread to discuss in more detail. but i agree that embedding it into the website would be good for everyone.

yes, we have that as high priority on our list. and the big challenge is to find a windowing framework that works cross platform. currently we are using windows forms (windows, menu and context menu) which needs to get replaced. then we need to figure out how the integration and user extensions should work. since there isn’t the perfect solution right now, we are waiting for the winner of the the ui framework wars in 2019 on .net core 3.0. let’s see.

image
btw. the EditorWindow node is only there for convenience (e.g. close on startup of finished project), you don’t need to put it somewhere. if you place a StateMachine node in the patch it opens the editor automatically, just like renderers. you can also place a StateMachine in a loop and dynamically create 100 of them.

i‘m following the UI frameworks development for the last 5 years. looks like there will never be the „eierlegende wollmichsau“ for UI programming. i doubt 2019 will change that impression.

xaml is definetely interesting hence uno sounds cool. question is, does it make sense to wait for some wonders or choose a pragmatic windows solution to move forward.

1 Like

yes, definitely worth waiting a bit, .net core 3.0 will change the landscape. i’d say the pragmatic windows solution is what we have right now with Forms.

my bets are on uwp

once microsoft manages to slip uwp into the windows chromium, we’ll know for sure

one thing that makes this very hard to use is lack of visual feedback regarding the automata state in editor window. Makes it very clumsy to work with.

the UI is the default from WorkflowFoundation, I think it was not designed to work at runtime. however, there are two places to get insights:

  • the log window gives you real-time feedback when something changes:
    image

  • the ActiveStates node will give you all current states in the patch:
    image

@tonfilm, btw. is there anything planned in gamma to have a simple way to open an UI window for a node. just like in beta. right click on automata node reveals automata UI ?

2 Likes

@u7angel there is a general system in the VL API that gives you the selected node on selection changed. with that, you can patch such a system. however, it doesn’t differentiate between left or right-click.

you can see that in action here:

thanks tebjan, this looks interesting.

but a strategy for gamma user interface extensions would be of value. if i recall right, we were talking about this at the vvvv summer camp…including the whole automata/timeline discussion. beta had a straight forward way of handling such things which is still missing in gamma/VL.

when we think about something like that, being able to have multiple windows and the ability to tab them, touches this topic.

This is pretty good. I’m not sure how ‘if’ conditions work when I have more than one transition from a state but this is a handy system. But maybe with one caveat:

.Net 5 (core)

1 Like

Added a simplified zip for gamma only users. @remony

2 Likes

I try to Export Project at vvvv gamma 2.6 and run file, but got exception!!

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at RehostedWorkflowDesigner.Views.StateMachineControl.SetDesigner(String filePath)
at RehostedWorkflowDesigner.Views.StateMachineControl.OnInitialized(EventArgs e)
at System.Windows.FrameworkElement.TryFireInitialized()
at MS.Internal.Xaml.Runtime.ClrObjectRuntime.InitializationGuard(XamlType xamlType, Object obj, Boolean begin)
at System.Xaml.XamlObjectWriter.Logic_EndInit(ObjectWriterContext ctx)
at System.Xaml.XamlObjectWriter.WriteEndObject()
at System.Windows.Markup.WpfXamlLoader.TransformNodes(XamlReader xamlReader, XamlObjectWriter xamlWriter, Boolean onlyLoadOneNode, Boolean skipJournaledProperties, Boolean shouldPassLineNumberInfo, IXamlLineInfo xamlLineInfo, IXamlLineInfoConsumer xamlLineInfoConsumer, XamlContextStack`1 stack, IStyleConnector styleConnector)
at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
at System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri)
at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
at RehostedWorkflowDesigner.Views.StateMachineControl…ctor()
at RehostedWorkflowDesigner.Views.StateMachineTabs.AddMachine(String name)
at RehostedWorkflowDesigner.StateMachineService.AddStateMachine(String name)
at VL_WorkflowFoundation.WorkflowFoundation.StateMachine_JrmSMngRBoDO07t63iDcIo.Create(NodeContext Node_Context)
at Machine_2.Main.Machine_2Application_ODb0lIhZy1cOIQE4POLruR.Create(NodeContext Node_Context)
at VL.App.AppHost.d__5.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at VL.App.WindowsForms.WindowsFormsAppHost.<Application_Idle>d__2.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

It looks like the designer file is not found. You need to place the file relative to the exe, in the same way it was relative to the vl doc. Or patch a logic to find the file locally. See also: https://thegraybook.vvvv.org/reference/hde/exporting.html

@tonfilm I place 'DemoMachine.xaml" relative to the exe still not work…(build at gamma 3.2)

Hi guys. Would you recommand the workflowFoundation as state maschine or is there another tool out yet?
Than I would give it a try.

I think it is the most complete and flexible solution at the moment. it can be improved by storing the data in a pin, so it doesn’t need file handling, making it a tiny bit easier to use. but having files is also a good thing sometimes. The editor can also handle multiple machines simultaneously, and a state can have a state machine inside, so it is quite advanced.

there are two alternatives, this patched one, as linked above in this thread: VL.Automata
and you could also implement the state pattern with VL, as it is done in VL.Elementa for the interaction, as linked here: https://github.com/vvvv/VL-Language/issues/8

Thank you. I’ll check it out.
** Charismatic Guy explaining the workflow with states, thanks for the link ;)

Hi, while testing this contrib I made this simple state machine :


DisplaySlotStateMachine.zip (2.3 KB)

Now just starting this create a monster memory leak. Is there something wrong with the way I’m using it ?

EDIT –
Damn, my bad indeed. Now in case someone wonder, don’t forget to add a Wait inside a transition, otherwise the StateMachine might be spinning forever until your computer explode.
image

1 Like