Ron

You can log in the user automatically, so you only need to know which user, and then pick up whatever he did last, and show the form where he left. So how to ID the user? A cookie with fast expiration is probably the best option. Public IP may be shared, but if combined with local client IP, within a short timeframe, it should be pretty secure. E.g. WebRTC JS API and the ICE protocol to get local LAN IP. It could be DHCP but within a short timeframe it should be ok for less critical apps. Last option to ID the user would be to log all mouse movements and key presses and create a personal time/motion profile of the user, and check for matching patterns

"now I'm in love with javaScript." JS is like a cute and clever woman - you never know exactly what she's gonna do, and how she's gonna do it, and if she will even do it, and if so, when she's gonna do it Any coder cannot help but being infatuated by such an interesting partner...

The only thing most people would need, is the DB and maybe DB access components if you cannot use what is in Delphi already. I use MySQL and microOLAP db access components, and it was not expensive. You may need some non-visual components or code, depending on whatever you make. There are of course many Sencha third-party components that you may get to work with Unigui. For instance, there is a calendar component, but I made my own based on JS code. It all depends on how complex your app is, and what it connects to. But for most typical projects, you only need the DB and db access, and then you're good to go.

procedure TMainForm.unimdateTimePickerChange(Sender: TObject); begin showMessage(dateTostr(unimdateTimePicker.Date)); end;

Sure, you can use url parameters to display any form you like as the app loads. If you use the standard login form, you can just autologin users going to other forms, to a fixed userid for differentiation, or you can make you own login routine.

Guys, we are on the same page on this. I too came in early with Unigui after having tried another delphiweb solution where the support just faded away and the company turned their focus on another app, and there were many of us who paid about $600 for that, and basically went away empty-handed. Now I clearly saw - immediately - that things were totally different with Unigui. The thing is that here we have one guy who is 100% dedicated - he takes this personally - and judging from his efforts so far, he will not give this up easily. A good teams is great, but it always depends on a very good leader, and in this case I say we have it. That is why I can put all my business in his hands, and I am sure that if Farshad has to get out somehow, he will give us the source code. The framework is brilliant, we can leverage the power of both Delphi and ExtJS to the max, interfacing with ISAPI, I almost don't know what more to ask for, except Websockets. The source code will come eventually, as we turn 1.0, or at least that is what I expect. Please correct me if I am wrong. Sure, things have dragged out, but things have also been pretty stable for a long time, and we can all appreciate the complexity of these things. To have a guy willing to dedicate such a big part of his life to make sense of this technological mess we are in, and give us the opportunity to use our favorite tools to get things done, is just great. So when I ask about the company, it is not because I do not trust Farshad or his ability to complete this project - far from it. I just want to know if things are even better than what I already assume. We have one super-dedicated guy, and this is his baby, and that's great - but what more do we have? I am not in the loop to make an educated guess - I am just curious.

You don't need to handle anything in the loginform, as the mainmodule beforelogin event is called first, so you handle it there, and set "handled" as you please. You can pick up the url params in mainmodule, and handle it all in the beforelogin event. That is the logic. As for posting to a session to affect its state, there is obviously a security question if you are going to let outside processes affect a running session. The session is and must be tightly linked to the client all the way, and I would assume you could get concurrency issues too if you start opening up the session for outsiders without some extra stuff handling that. Data is all about consistency, and thus security.

Hi Farshad, could you please elaborate on the staff of FMSoft, how many developers you have in the company, and to which degree the future development of Unigui is dependent on you personally being active and available for the company. Also I realize that there is in effect a wider network of developers coming into play as a result of this forum, and can you please elaborate on how many of these people you consider to be part of a stable support group that may be around in the future, to eventually carry the development forward if FMSoft somehow gets incapacitated. Opening up the complete source code will of course provide added security for future development, and should be done as the beta is over with, and I guess that is also the plan, so that is great. All these things are about security and should be considered.

I guess it will nearly always be preferable to stay in the session, as the other process may halt and thus fail to trigger the new session start. If you know for sure that you will get a new session start no matter what, that approach may be more stable as there is less complexity. The critical thing is the time spent, and I guess up to a minute should be ok with the current session, but what about let's say half an hour? - that is too much of course, to keep it alive on a timer, so then a new session is probably better.

You can pass a parameter in the URL, but it will create a new session, so you have to handle the login, catch the correct user ID if necessary, and process the request. I assume there is a login. So first you construct a response url, where you put in a key that you generate, and you store this key in the db linked to the user, and give it a timeout datetime, and you pass this url to the shopping cart as the response url they shall trigger at payment accept. And in mainModule, beforelogin, you catch the url param with the key, check it in the db, and if it matches you process the request, and put up whatever response, logging the user in at the same time, pulling up whatever order was just accepted. All you need is a key that you pass and get back again and check, using the url as storage. You put a timeout on the whole process, like 30-60 seconds, and in that window you accept the key and process the req, and if not you don't log the user in, but put up another message.

Here is some code in that area: http://disprein.blogspot.no/2009/04/creating-win32-security-descriptor-with.html

Right, you can use the peerIP, the local time of day, the local outside temperature, client browser properties/client opsys...in short whatever, to create different responses from the server upon login or after login. That is the nature of a server - you decide what is to be served, on which conditions. If you have a predetermined group of people, user access may be the easiest way. If there is no user login, other available client data may be used to create different server responses.

Sure, you can use url params, like domain.com?page=master and domain.com?page=worker, both served by a single server, standalone or not, and you will see different forms if you set it up like so, when loading the app. If you want to avoid url params, I think you need a webserver, and then you can redirect domain.com/master to a DLL and in the redirect you can insert the url params. If you totally want to avoid url params, you can use a webserver and redirect to two different instances of the same DLL, using the url to determine category, or a local file being loaded at mainmodule create. By "sending commands", you do not really send commands to a page but to the server, and if you create a server-side routine that checks a db for changes, you can then present that on the other page. The app can know which category it is in (master/worker) and query only the commands intended for it. For more direct browser client-client communication, you have to use websocket clients in each web client, and set up an extra websocket server to connect the clients.

Just discovered how to do it on apache, just use DirectoryIndex <Directory "C:/mydlldir/"> Options FollowSymLinks ExecCGI AllowOverride None Order allow,deny Allow from all DirectoryIndex mydll.dll </Directory> Alias /myapp "C:/mydlldir" Navigating to http://myserver.com/myapp will load the dll, hiding the extension in the url. You should be able to set the directory index file specifically in IIS too, of course.

Well, I was able to setup a system according to this idea mentioned above, and test it on a live server with apache, but the problem was the loading time of a new standalone server: 15 seconds from login vs 5 secs using a single dll. I used a login.dll running under apache, which spawned a new standalone unigui server for each logged in user: it executed the exe on a new port for each user, by running the apache on a user with network resources access privileges. So that worked. Uplading a new version of the standalone exe worked fine too, with setting the firewall rule for the file, opening up for all ports. But due to the extended loading time, 15 secs vs 5 secs when using a dll, this will probably not work so well. But I kind of liked the idea of separating the login from the main application, as you then get very fast loading time of that small login app, and it provides a small waiting spot for the user while redirecting to the new active updated app, informing of what is happening. I found a working compromise: use one login app, and two main apps, where one is the active at any time. At update, one dll is updated and set to active, and the main apps notice that, and inform the user of the option to update. At update, the user is kicked back to the login app, but I have an extra session layer with the session key in the url param, and this gets picked up by the login app which sends the user over to the new active mainapp dll. One could use cookies instead of such an extra session layer. This way users may switch to the new active app individually, and I have separated the login from the main app. From login to main app load, I give the main app 5 seconds to confirm the new session key in the db, and it is valid for 12 hours, from that public IP. So this is possible, with three DLL's, one for login/session control, and two main apps where one stays active at any time, making the other available for updating. Maybe this could be done even without a login app, and use the webserver to direct the user to the active app, using a url rewrite based on some data from the file system or the db, setting the url of the active app.

"...in this case you need to sepcify it manually..." Why do you then need to specify it ? Please clarify. "...retrieved from request header parameters 'Referer'..." How early, in the startup process, can this be done, and how?

There are a number of ways to get a file to unigui, first some acting as server. 1. Use the built-in indy HTTP server, and the uniServerModule events OnHTTPCommand and OnHTTPDocument. Then you have to encode the file before you send it. There is no point in setting up an extra HTTP server, as unigui contains one already. 2. Use an indy TCP server in the uniServerModule, and a TCPClient in the VCL app. This is by far the easiest and most straightforward way, use TCPClient.IOHandler.writeFile on the client side and ReadStream on the server side. 3. Use an FTP server in the uniServerModule, and an FTP client on the VCL side. FTP is a bit more complex than TCP, but also provides more options. 4. Use an SMTP server and send the file as a mail attachment, or any other protocol. Of all these protocols, TCP is the easiest one to set up for simple text/binary file transfer. Of course the TCP server would have to run on a different port than the built-in unigui indy webserver. Historically, I think it is safe to say that FTP and TCP have been the primary protocols for binary internet transfer, especially on upload, with HTTP Post gradually taking a bigger part of that pie as working encoding solutions have been worked out. The reason for the increased use of HTTP Post for binary transfer, is the ability to then use the webserver which is already there, not having to think about opening extra ports in the firewalls for another listening server, and so on. The challenge with HTTP Post file transfer is the encoding of the data, and also to some degree the transfer process. With TCP or FTP you do not need to think very much about that. If anyone has tested and working code for HTTP Post of binary files using indy, please post it here. You could also get a file to unigui server, with unigui acting as client. Just send a HTTP command (i.e. including the link) to trigger the unigui server to initiate the download of the file, which it then does, moves it to someplace and then generates a download link. This of course assumes the file is already available online.

I've made a test project according to the idea I mentioned above, download at http://s000.tinyupload.com/index.php?file_id=26843721044701981814 It contains two projects, one loginapp and one mainapp. At login, a new standalone server will be created, on a new port. The mainapp standalone exe's are located under the loginapp folder, in separate dirs, with the dir name indicating the version. At update, control will return to the login app, and the running process will be killed and a new standalone server process created, on the new exe available in the new dir. The drawback is that the main apps will all be standalone servers, but there will be one for each user, so there should really not be any resource issues as long as the server box keeps up. Hard to say what is more stable: x threads in an Apache/IIS container or running them directly under the operating system as separate processes like this. But here you can at least get individual updates, where anyone can update when they want to on an individual basis - think I will try it out.

Let's say I have an Apache or IIS main server, where the user logs in. At login I then execute a standalone server at a different port, serving the main application - one such standalone for each new user. As an upgrade is available by timer->db/filecheck, the user is served a notice in the app, having the option to upgrade, which then kills the standalone server, routes the user back to the main login app which keeps the session, and creates a new standalone server based on new exe, again serving the secondary app to the user.

Problem is that with a single server, you cannot discriminate between sessions/users, and either keep'em all or kill'em all. Waiting for all to be inactive may take forever. So you then basically need one server for each user, and then you can upgrade only those who are not active. You could setup a system which spawns a new server for each user, and then another update system to kill the right servers for upgrade at first inactive - but that is quite complex. The goal is to upgrade without losing the session and thus disconnecting the user. What about using two applications, where one is a shell application which is not updated, but only keeps the session - and then another main application which gets updated? That may be possible, two DLL's served by one server, using the ISAPI loader to update only one of them, and as the second app session terminates the user is directed to the first app, which then loads the second app after update...as it also loads the second app after login, and the user is all the time having the shell app session alive. But to do upgrades on an individual basis, requires separate servers. It is the nature of the issue, as individual and group are two separate domains, and cannot be joined.

I guess it all depends on the nature of the signal that you are monitoring, i.e. the rate of change, the predictability of that range or the function of change. If it is RPM, which changes constantly like every second, you might as well use a timer, as you will be sending/getting data every second anyway. No point in making it complex if you always know when the data comes. However, if the data changes now and then, and it is a point to keep the client/server communication to a minimum, and critical to get the update when it comes, then a more complex solution might be in place. There is nothing wrong with a timer in itself, and you can log it, and set up other systems to monitor it and whatever. Your box is run by a Ghz timer, and it works great, so timers are super basic in computer systems. Without them, like in the form of crystals, we would have nothing. Timers are like frequencies, or patterns, symphonies of energy... they are the building blocks of the entire universe etc etc...don't fool with timers!

You are long polling the unigui server through the client instance, which has the db connection and thus access to the fresh data, or another webserver that you set up somewhere, that has access to the data you need. For instance, I have a cash drawer and receipt printer installed locally with the customer, and when the cash drawer is opened, I make an http call to the local windows service controlling the cash drawer, which is running an http webserver, and within that service I do not respond to the http call until the drawer is closed. On the unigui end I pick up the fresh db results as the http blocking long polling call finishes, because I then know the service app has saved the cash drawer state to the db. From a uniHTMLFrame I assume you can do some of the same stuff, make a long polling ajax call somehow, to the unigui server through the client instance. I also have the option of a timer, instead of long polling, to get the cash drawer status, and the last option is no checking of status. But new regulations now demand that no POS transactions may be done while the drawer is opened, so that state must be logged.

This kind of functionality - resources - is not something I typically find in the calendars/schedulers available, and only in the more advanced implementations, like ExtCalendar and some others. I too speculated about this option in calendar panel, but as far as I know, it did not exist. But maybe this have changed, not sure, but the thing is not heavily documentet from the ExtJS side. But I needed so many different options, that it would probably have been a bigger nightmare to use the calendar panel, than to write my own calendar. I too would like a very advanced, customizable day/month calendar made purely in ExtJS, with push functionality, rooms, graphics and all the bells and whistles. If I had a free year or two, I'd like to make that, but I'd have to learn ExtJS well first, and that takes another year...

In your code you probably need some JS to catch the browser resize, and what I would use is something like this pseudocode: window.addEventListener('resize', resizeFrame, true); function resizeFrame() { sliderbox.width = MainForm.htmlFrame.getWidth(); sliderbox.height = MainForm.htmlFrame.getHeight(); drawSlider(); } If you can post your project, someone can take a closer look at it.

What may work, is using an uniHTMLFrame, containing some javascript, where you load a websocket client, which then connects to a websocket server you have running, like a nodejs server. I am in the process of trying this, and I'm going through the various websocket js libraries around, and I was able to connect with one of them, think it was Faye, to a nodejs server, but there was some other issues, so I kept looking. Going to take another closer look in some days. A list of such libraries is here: https://deepstream.io/blog/realtime-framework-overview/ Maybe it is possible to find a working library - I don't know - some of them use their own client libraries, and others use the raw websocket client. I need to broadcast db changes to all connected clients in real time, triggering the client to load the update, if relevant.