Seeing the Front Panel of a vi that starts before I log on.

[JohnEE]

Hi All,

I've written an application that needs to start when the computer reboots; it can't wait until I log on.  That's easy, just use Task Scheduler to create a task that will run when the user is not logged on and is triggered at system startup.  But now when I do log on I can't get to the front panel of the vi.  Is there a way to do that?  I came up with a complex way using pipes to transfer control data, but there must be an easier way.

Any help would be appreciated!

Thanks!

John

[rolfk]

Read about desktop isolation and user sessions. Windows did allow interaction between session 0 (where services and your application runs) and other sessions 1 and higher, but restricted that significantly with Windows XP and then in Windows 7 even more for security reason. I’m not sure there is still any direct possibility left, but if there is I would hesitate to use it as it could be plugged any moment by Microsoft.

The way to deal with this is indeed by Inter-application Communication and you need to choose one that can not only go across process boundaries but also session boundaries, so anything network based is pretty much a requirement. I personally tend to go with my own protocol based on binary TCP/IP but anything using TCP or UDP underneath will work.

[santo_13]

---

@rolfk wrote:

Read about desktop isolation and user sessions. Windows did allow interaction between session 0 (where services and your application runs) and other sessions 1 and higher, but restricted that significantly with Windows XP and then in Windows 7 even more for security reason. I’m not sure there is still any direct possibility left, but if there is I would hesitate to use it as it could be plugged any moment by Microsoft.

The way to deal with this is indeed by Inter-application Communication and you need to choose one that can not only go across process boundaries but also session boundaries, so anything network based is pretty much a requirement. I personally tend to go with my own protocol based on binary TCP/IP but anything using TCP or UDP underneath will work.

---

Thanks for demystifying the feasibility. Instead of TCP/IP or UDP, I would recommend gRPC as the core of gRPC is a service and this could be the one you launch before login.

https://grpc.io/

https://github.com/ni/grpc-labview

[rolfk]

---

@santo_13 wrote:

Thanks for demystifying the feasibility. Instead of TCP/IP or UDP, I would recommend gRPC as the core of gRPC is a service and this could be the one you launch before login.

It’s a good recommendation.MQTT could be another one or Shared Variables or …

But none of them is “instead” of TCP or UDP, but simply build on top of them. 😀

Your own protocol has the advantage that you simply implement your own listener in the background app and don’t have to install and support additional software that must run as service or session 0 application too. Disadvantages are likely more initial work for the protocol development and additional trouble if you also need security and/or authentication. 

[JohnEE]

Thank you both for your replies!  I had been hoping that there was a way to make the front panels appear when I logged in, as opposed to making a separate vi to communicate with the one that starts with Task Scheduler.  But that would be too easy...

A while ago I wrote some VIs that I ran as a Windows Service and I communicated with them using Named Pipes.  Any thoughts on Named Pipes vs TCP/IP, UDP, and gRPC?

Thanks!

John

[rolfk]

Named pipes should work too: https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipes

[JohnEE]

The simple answer to my original question is that you cannot directly access the front panel of a VI started by Task Scheduler before logging on (or started as a windows service).  You must communicate with the running VI to exchange data with it.  As @rolfk points out you can create a protocol that uses TCP or UDP.  gRPC, as suggested by @santo_13, looks like it will work as well.  I spent some time with the excellent LabView implementation/tutorial suggested by @santo_13, but it seems more complicated than I need for this project.  I will keep it in my toolbox for the future. 

I've opted for the win32 Named Pipes, which I had used previously.  I've attached my Named Pipes implementation in case anyone is interested.

Thanks so much @rolfk & @santo13!

John