Running a web app as a standalone exe, a console screen pops up. It would be nice to see some info in this screen. Like how many current connections, mem used, etc… Could be interesting feedback
That would be nice
You can however print messages to that window from the app by using Print(“Hello, world.”)
@Albin Kiland Wow, that is a cool tip! Will definitely come in handy and we probably can write my suggestions ourselfs.
Yepp. I use Print all the time for debugging/log messages
nice! Putting the following code worked fine (some delay on the close)
in the webpage.open:
app.Connections = app.Connections + 1 print("Current Connections: " + str(app.Connections))
and in the webpage.close:
app.Connections = app.Connections - 1 print("Current Connections: " + str(app.Connections))
Just remember that browsers create more than one connection at a time to your app, so all this tells you is how many instances of WebPage1 are in use at any given time.
Interesting. For the moment I only see one conncection per browser I open, but is there an alternative way to show how many connections (users) are using you app at any time?
Would it be possible to simply record users by the time they connect plus their IP, no matter the number of connections they initiate ?
WebApplication.SessionCount will get you closest.
If you’re program will be used by corporations, you may run into trouble with this. Some companies have more than one public IP address for load balancing, so you can out guarantee it will stay the same.
But guys, this is what SessionCount is for.
I have an admin page that allows me to see open sessions and see who is logged in. It’s not very hard to do.
That is interesting. I always assumed that once connected, one would keep the same address for the duration of the connection, and that while connected, one user could not have 2 different ip addresses (which does not mean that one user, on two separate connections, should have the same ip address). I thought that this would be a way to detect shared login credentials (which is important if the licencing model is per named user)
I ran into this with users from HP back in 2002. The users regularly bounced around a class B block within their sessions. The way I kept track is how many active sessions did a user have simultaneously. That a showed me better than anything else that the user was sharing logins. These days I have people logging in on their tablet and desktop at the same time but we only worry about it when we have a client with compliance issues.
Bob, We will definitely be interested in that for our project when the time comes.
When you realize that the connections from the browser to the web app are not persistent, it makes a lot more sense. They’re just http requests which only stay connected long enough to get the data they requested.
I use the console screen for a number of things.
My web app is intended to run on a local LAN for device control It’s really an app with a Web based GUI and not a web page. So it’s licensed to the end user. When the user first starts it up, the console interface is used for the person to enter their name, email and license key. Then when the App object of the app does certain things. this information is logged to the console. So like if one of the devices in the system gets connected - that’s logged. If someone using the app changes something - that gets logged, etc. It’s a very useful screen.
Most Xojo web edition users have a traditional web “site” idea stuck in their minds when using WE. I don’t. To me, a WE app is just another app. It just has a Web based UI. That Web based UI has certain limitations due to browser security, etc. but it sure works quite well.