Jump to content

Oliver Morsch

uniGUI Subscriber
  • Posts

    368
  • Joined

  • Last visited

  • Days Won

    18

Posts posted by Oliver Morsch

  1. Additional you can use a (your) function "FDataModule" in your DataModule as follows:

     

    function FDataModule: TFDataModule;

    begin

      result := uniMainModule.FDataModule;

    end;

     

    Instead of "uniMainModule.FDataModule" you could you use a (String)List/Array/HashMap/... as UniMainModule field with containing all datamodules for the current session; so you have not to declare something for each of your modules in UniMainModule.

  2. This is not thread safe !!!. (session list ist a global var and there is no access control, ... )

     

    Better you store a reference to your DataModule in a Field of TUniMainModule. That would be easy to read/write - no thoughts about sessions and threads, because thread safe and per session by default.

     

     

     

  3. #2

    Use "free form" and you are free...

    UniGui forms that are not in use (displayed) will be freed for less memory consumption. If you show you them later again they are created again, but so prior changes are lost.

     

    #4

    That is how HTTP works: Server can only answer a request - if there is no request, there will be no answer.

     

    #5

    Not every keystroke or mouse move will be sent by default. Would be too much traffic.

    If you can use such high traffic depends on your own system. Do you have view users in a local network, there should be no Problem. Do you have many users over (slow) internet connection, there is a Problem In second case you should use (client side) JavaScript...

  4. #1:

    You have "Free Form" and "UniGUI managed Form". Free Form you must create/free by yourself, you can have more than one instance of it per session at a time. With UniGui Form you have only one per session, create and free will be done by uniGUI. accessing the form (function) will create it, close will free it. The difference to Delphi/VCL is that it can't use global vars for that, because each user/session wants its own instance. So there is a function "MyForm" that delivers the instance for the current session (including create when needed).

     

    #2:

    So that auto create (on access and show) and auto free (on Close) works correct.

     

    #3:

    See #1. And be aware that you do not use global vars.

     

    #4:

    UniTimer fires on client side (browser). That is needed, because browser must first send a request, otherwise Server could not answer (send something to browser).

     

    #5:

    So every key press is send to the Server -> much traffic. You can use Client Events (JavaScript in browser) and then use AjaxRequest(...) when you must process something on Server.

    • Upvote 1
  5. Rav, on 02 Jul 2015 - 11:33 PM, said:

    I looked through your long polling application, very informative, thank you!

    I think that's a little bit complicated scheme, does it have flaws?

    There are 347 downloads - and no bug reports till now...

     

    Rav, on 02 Jul 2015 - 11:33 PM, said:

    Are you planning to add WebSockets example to it?

    No.
  6. As far as I understand the TUniTimer being placed on the main form is instantiated in every session,

    Yes.

     

    so with the 100 open sessions we'll have 100 timers on the server side.

    No. TUniTimer runs/fires on client side (browser). But for every "onTimer" the browser sends a request to ther server. So you have very much network trafffic and the server must handle all these requests.

     

    Is this the right way of constructing the application?

    In my opinion: No. See option 2 and 3 in Post #4.

  7. In other words the clients display some server info and can modify some server parameters remotely.

    When the server parameter is changed (it could be also done due to other internal reasons) the server sends

    a message (delphi record) to all clients, they receive it and update the display info accordingly.

     

     

    By default web servers can't send messages to (all) clients. Servers can only answer a request.

     

    So you can do one of the following;

     

    - using TUniTimer (client (browser) sends every x seconds a request for updates to the server)

     

    - using "web sockets" (HTML5)

     

    - using "long polling" (see here)

  8. But you can show a VCL form with a TWebBrowser in it. So it looks like a standard program (with a web gui).

     

    • create a normal VCL (not UniGUI !) form in your project that is shown at startup
    • put a TwebBrowser onto this form (Align: alClient)
    • onFormShow: WebBrowser.Navigate('http://localhost:8077/');
    • onFormClose: Applicatin.Terminate; // shuts down server if form is closed

    To use a new browser version that works with UniGUI you must must add a registry entry or change !DOCTYPE (second I don't know how doing in UniGUI, but first works for me)

  9. Instead of

    ExtractFilePath(Application.exeName)

    What is the difference ?

     

    If you use ISAPI-DLL this could be another path (not dll path).

     

    3. To retrieve (client side) DeskTop directory, can i use

    In MainModule :

    GetSystemPath(CSIDL_DESKTOPDIRECTORY)) ?

    You cannot  get/access folders of the client (in a browser window).

  10. About thread handling in UniGui: it is simple!

     

    Don't use global vars, instead of that use fields/properies (in the form-/module-/anyOther-class definition)

     

    Then each session accesses only objects in its own thread (controled by UniGui) and you never read/write memory used by other sessions. Each session has ist own instances of all.

    • Upvote 1
  11. @ Oliver: sorry, can you rephrase?

     

    Farshad wrote in post #2:

     

    OnException event is only for non-visual code.

    ShowMessage() and etc. will not work here.

    ...

     

    I think ServerModule is another thread/context and something like ShowMessage() there will produce other problems.

×
×
  • Create New...