Jump to content

albertovesx

uniGUI Subscriber
  • Posts

    598
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by albertovesx

  1. You don't have to rewrite your code, only "refactor" it a bit. Callbacks work in VCL the same way, so it is still 1 code base to maintain. And the lastest UniGUI version has a built-in support for anonymous callbacks, so you dont even need to create your own forms for dialogs and messages.

     

     

    ExtsJS is representation library for JS (JavaScript), UniGUI is a library for ExtJS, so in general UniGUI is a library for JS too. JavaScript is asynchronous (no blocking code), so every library based on JS has the same asynchronous nature, be it ExtJS, JQuery, Dojo, ExtGWT, UniGUI or anything else.

    Why is JavaScript asynchronous? Would you like your browser to halt while browsing internet besause some js code called internally a blocking function?

    I guess no, user experience (no lags) is way more important than lazy programmers, isn't it? There are no threads in javascript, only callbacks. You either use them, or don't write for web at all.

     

    You propose to put all logic in a separate thread in UniGUI application and you can since Delphi (WinAPI actually) has threads, but here comes another problem of the Web. In ordinary desktop app when you say "I want to show a message" you just do it and BAM! it appears on the screen instantly, because you app and what user sees on screen is the same thing, or single layer.

    In web you have 3 layers: your app (server), web browser (client) and a network (internet/lan) beetwen them. When you say "I want to show a message" client browser doesn't give a fuck (excuse me for that, but it suites this perfectly) about what you want. You must somehow tell it to show message, and to do that you need to pass the network layer, and here comes another problem...

    HTTP protocol used for WWW is one-sided - client always initiates connections to server, not the other way. You can't connect to client browser from your app and say "I want to show a message". The technology to move some information from server to client is called "pushing", and there are only 3 ways known to execute that:

    1. Return information in the same connection. When user pushes some button in browser on web page, javascript generates a connection from browser to server, assignes a callback function to process any information that server may return, and returns without blocking so web page won't stall waiting for a response from server. This is called AJAX. And the first "A" letter stands for Asynchronous, the rest is pretty obvious. Thats how ExtJS works, how UniGUI works, how 99% of js libraries work in gereneral. Thats why ShowMessage in uniGUI doesn't block execution, or client browser will never know that he must show that damn message. You want UniGUI to handle it internally, but how? Can you imagine it? It must return from event or browser won't show a message, so it must assign some internal callback to force browser to make another connection when message is closed, and only then it somehow needs to find an entry point to code that is located after showmessage... Well, perhaps it is possible, I'm not that good at assembler since it requires some freaking machine code magic and mambo-jambo with CPU registers to do that, not worth it. By making anonymous function you tell UniGUI yourself "execute that code", and everyone is happy.

    2. Polling. Client browser has a timer that periodically calls server to get information about any updates. Your method of separate thread for business logic must use polling to inform client just about anything: appearing messages, forms, dataset changes etc. And all those updates will happen with a delay because you can't poll every 1ms and network also has a latency on top of that. Imagine - you add a row to dataset, and client will only see it 1-2 seconds later, that UI will be horrible. So polling is used only for updates that tolerate delays like chatting, messengers, notifications and other unnecessary stuff.

    3. WebSockets. Its a new technology, supported only by several browsers, has problems with network infrastructure (firewalls) and many more. However it can become the future of web, who knows. But not now.

     

    p.s. It was a brief and very simplified info just for you :rolleyes:

     

    This information is very useful. We really need documentation like this. Thank you.

  2. ive got an app running fine.. no trouble.. but Im a little confused about something.

     

    I took my mainform, and renamed it to loginform.. Loginform is the first form that loads.. my question is, why is that? where is the code that tells that form to load first?

     

    I changed the creation order in the project, that didnt affect anything.. All unigui forms seem to have been derived from the same class etc. so what makes that first form different, and where in code does it tell it to load that one first at startup?

     

    Gordon

     

    You have to add this line in the form you want to be the main form and remove it form tha actual mainform:

     

    initialization

    RegisterMainFormClass(TfrmMY_MAIN_FORM);

  3. In uniGUI only MainForm, MainModule and user DataModules are automatically created when session started. Other forms are created on demand.

     

    Hi, Is it posible to do the contrary. I mean, I want that some forms stay available like the mainform.

     

    Best regards.

  4. I don't understand you.

     

    Well, if I understand, you have to change the property MainFormDisplayMode located in uniservermodule. You probably have the mfWindow value and you must change it to mfPage.

     

    Best regards.

  5. I'm using a TUniDBGrid linked to a TDataSource, and the TDataSource linked to a TTable.

     

    When I do:

    Table1.Append;

    Table1.FieldByName('campo').AsString := value;

    Table1.Post;

     

    The record in DataSet automatically moves to the new record (ok!)

     

    But in TUniDBGrid the selection is currently in the previous record.

    When DataSet fires update to the linked components (including DBGrid), the record change to the new position,

    But TUniDBGrid fires some Refresh event after that and set the previous position to the DataSet according with the original selection, losing the new record position.

     

    This occurs only in WebMode.

     

    ----

    I try to do that:

     

    UniDBGrid1.DataSource := nil;

    Table1.Append;

    Table1.FieldByName('campo').AsString := value;

    Table1.Post;

    UniDBGrid1.DataSource := DataSource1;

     

    And then works perfect (when the Grid refreshs, the new record comes selected).

    -----

    Is this a bug or how to workaround ?

     

    Same error happends to me. And I solve it in the same way. I think it is a bug.

  6. This happends because there is not path to the dcu file generated with the first build. So you need to add the directory in Tools/options/delphi options/library/ --> library path. Probably is C:\Users\Public\Documents\RAD Studio\9.0\Dcp

     

     

     

    http://www.unigui.co...r-version-0-88/

     

    0.88.1.943

    +----------------------------------------------------------------------------------------

    - 0001282: Form's values aren't synced when deactivated.

    - 0001281: UniTreeView: MainForm.Close in OnClick event.

    - 0001203: UniTabSheet: PageIndex bug.

    - 0001261: OnDropDown event for ComboBox.

    - 0000640: UniSession SendFile() method

    - 0001284: UniSession SendStream() method.

    - 0001268: UniDateTimePicker: ShowBlankDate property.

    - 0001270: UniDBGrid: Float/number field ignores decimal/thousand separators.

    - 0001042: Grid Cell font changes when editing cell.

    - 0001274: UniDBGrid: Embedded editor's Font doesn't match Grid's Font.

    - 0001278: TUniToolButton: Transparency Property.

    - 0001279: Bug when received string contains a "&".

    - 0001280: Critical bug in Form parameter setting logic.

    - New Demo: DownloadDemo-2

×
×
  • Create New...