Jump to content

ZigZig

uniGUI Subscriber
  • Posts

    352
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by ZigZig

  1. Hello,

     

    I think that is a normal behavior of your browser, not related to uniGUI, it is something about security settings in your browser (search "fakepath" in Google, you'll find technical explanations if you are interested).

    .

    Anyway, I always had this "C:\fakepath" since I use TUniFileUpload (for years): files were always correctly uploaded.

  2. Hi,

    You can use swapStyleSheet function.   Try something like this (used to work in old versions of uniGUI, not tested in newer versions) :

    UniSession.AddJS('Ext.util.CSS.swapStyleSheet(''/ext-4.2.1.883/resources/css/ext-all-gray.css'',''/ext-4.2.1.883/resources/css/ext-all.css'');');
    
    UniSession.AddJS('Ext.util.CSS.swapStyleSheet(''/ext-4.2.1.883/resources/ext-theme-gray/ext-theme-gray-all.css'',''/ext-4.2.1.883/resources/ext-theme-classic/ext-theme-classic-all.css'');');
    
    UniSession.AddJS('Ext.util.CSS.swapStyleSheet(''/uni-0.94.0.1024/css/uni-xtheme-gray.css'',''/uni-0.94.0.1024/css/uni-xtheme-blue.css'');');
    
    UniSession.AddJS('Ext.util.CSS.swapStyleSheet(''/myApplication.dll/ext-4.2.1.883/resources/css/ext-all-gray.css'',''/myApplication.dll/ext-4.2.1.883/resources/css/ext-all.css'');');
    
    UniSession.AddJS('Ext.util.CSS.swapStyleSheet(''/myApplication.dll/ext-4.2.1.883/resources/ext-theme-gray/ext-theme-gray-all.css'',''/myApplication.dll/ext-4.2.1.883/resources/ext-theme-classic/ext-theme-classic-all.css'');');
    
    UniSession.AddJS('Ext.util.CSS.swapStyleSheet(''/myApplication.dll/ext-4.2.1.883/uni-0.94.0.1024/css/uni-xtheme-gray.css'',''/myApplication.dll/ext-4.2.1.883/uni-0.94.0.1024/css/uni-xtheme-blue.css'');');
    
    UniSession.AddJS('Ext.util.CSS.swapStyleSheet(''/myApplication.dll/uni-0.94.0.1024/css/uni-xtheme-gray.css'',''/myApplication.dll/uni-0.94.0.1024/css/uni-xtheme-blue.css'');');
    
    

    You'll need to adapt the code with newest ExtJS Path, uniGUI Path, dll name and the name of the theme you want to use.

  3. Hello liteci,

     

    You can try something like this:

     

    procedure TFormMain.UniFormActivate(Sender: TObject);
    var
      C:TUniClientInfoRec;
      SessionID:String;
      IPAddress:String;
      BrowserType: string;
      BrowserVersion: Integer;
      OSType: string;
    begin
      SessionID:=UniApplication.UniSession.SessionID;
      IPAddress:=UniApplication.RemoteAddress;
      C:=UniApplication.ClientInfoRec;
      BrowserType:=C.BrowserType;
      BrowserVersion:=C.BrowserVersion;
      OSType:=C.OSType;
    end;

    see http://forums.unigui.com/index.php?/topic/1486-how-to-get-client-ip-address/?hl=uniapplication.remoteaddress#entry5654 

  4. Hi again Davie !

     

    I didn't run YOUR executable because it is not compiled in same uniGUI version as mine (which is the last one), so my browser stops on "Loading" page.  That's why I asked you what is your uniGUI version, but you didn't answer.

    As I wrote in my previous answer, I didn't notice odd effects on Chrome and FF.

     

    If you consider that you can live with the current speed, I guess that this "Active bug" topic named "Chart is slow" can be close (especially when your first words are "EXTREMELY SLOW"). 

  5. Hi Davie,

     

    I just loaded and tried you "tiny" project (which is NOT so tiny).  I DIDN'T NOT note any slowness, even when clicking on "load valuation with 300 points": when I hide or show a series, it responds in LESS THAN 0,5 SEC (tried on Chrome and IE11). 

    IMHO, your test case doesn't show any problem of slowness.  On IE9, it is a little bit slower... but that's IE9 :)

    What is your version of uniGUI ?

     

    I didn't notice your newer issues (graph not building or not refreshing) on Chrome, Firefox or MS Edge.  IE11 has some issues with javascript, that's a known thing, but it is not related to uniGUI.  And as Farshad says, it is probably related to the way you try to hide and show ExtJS components (IE probably doesn't execute scripts on hidden objects).

     

    So as far as I can see, there is no bug related to "Chart is slow" (which is the title of this topic), is there ?

    • Upvote 1
  6.  

    Davie, you can get source code if you buy a license...

     

    Yes. Let me remind that source code for core library is still not distributed.

     

    ; dbExpress, dbGo and FireDac components are not thread safe. 

     

    Well, they are thread safe if you don't share same control with more one session which is automatically done if you put them on a MainModule, a UniForm,, a UniFrame or a DataModule which is created from uniGUI wizard.

     

    You are right, obviously! 

  7. You say that If I use the " DM:=TDataModule1.Create(Nil) "  way of instantiating the object, you made it sound like <to me> that this object would/could be used by ALL THE SESSIONS?

    Actually no, I don't say that.

    I say that you TAKE THE RISK to.  I cannot say more: you didn't provide a test case, so it is impossible to figure where, when and how you create (and destroy) your datamodules ; it is also impossible to see if you have global variables into your datamodule unit (such as "var DataModule1:TDataModule1").  

    For the rest, I think that Farshad made the point perfectly clear.

  8. Davie,

     

     

    When I write "TUniDataModule", it is all about making the difference with VCL DataModule. But you are right, it is basically the same class, I should write "uniGUI Data Module".

     

    Anyway, look how uniGUI DM is instantiated :

    function DataModule1: TDataModule1;begin  Result := TDataModule1(UniMainModule.GetModuleInstance(TDataModule1));end;
    You can see that uniGUI does'nt call "Create" method, but "GetModuleInstance": you'll get one specific DataModule for each UniMainModule (thus for each session).

    So yes : there will be several DataModule objects (one per session) if you use uniGUI DataModule.

     

    Please notice that uniGUI doesn't use standard object constructor, as you want to do :

    1. DM:=TDataModule.Create(Nil)

    2. DM:=TDataModule.Create(uniApplication)

    3. DM:=TDataModule.Create(Self)

     

     

    With your way (TDataModule.Create), you take the risk to get only ONE object, whom parent is TUniApplication. Each session (each MainModule) would reference this same unique object. So yes: it is all about thread-safe and non thread-safe components.

    If you want to avoid this issue, just use UniGUI DataModule, which instantiate new DataModule for each new session (UniMainModule.GetModuleInstance());

     

     

    About TfrxRichView, it is exactly the same question; how is it coded? Are you sure it doesn't use global variables or methods? Are you sure that it is designed to run in a multi-thread context? Are you sure that when you create a new report, you won't share global variables or methods (not encapsulated into an object) with another one from another user?

    If you want comments from people that used FastReport and uniGUI, just search in this forum: http://forums.unigui.com/index.php?app=core&module=search&do=search&fromMainBar=1 : you'll find a lot of topics saying that Rich Text gets problems with uniGUI.

     

    UniGUI is still in (late) beta stage : you can try it, use it, comment it, test it, and even hate it. But it is intended to work as it works, with some technical limits (just like every framework): you need a DataModule ? Please use unIGUI DataModule, not standard VCL DataModule. You need Rich Text reports components? Please be advised that they are not stable with uniGUI, because of global variables and not thread-safe mode. You need full documentation? Please wait for version 1.0. You don't want to pay? Please don't hope to get full support.

     

    Oh, by the way: I also have been doing object programming for decades now.

    I don't know everything about uniGUI (I discover new things every day), I can make errors and misunderstand how it is internally coded. I use this forum to ask and answer about uniGUI, just like everyone here. But I don't use this forum to say that uniGUI should be written by FMSoft in a different way. I like some stuff, I dislike some technical limitations. UniGUI is what it is, no more, no less.

  9. Marlon, you are totally right about FireDAC.

    But I guess that with standard TDataModule, you won't get your first condition in a uniGUI context ("A connection object and all objects associated with it are used by a single thread at each moment.").  So if I understand, FireDAC+uniGUI will be thread-safe with TUniDataModule (edit : with uniGUI Data Module), but not with standard TDataModule (edit : with standard VCL Data Module)... and Davie want to use standard TDataModule.

  10. Davie, you can get source code if you buy a license...

     

    About DataModule vs. UniDataModule: even if you are not sharing your DataModule with other threads, what will happen when several concurrent users will access your web application at the same time ? Each user will create his own session... thus his own thread!  Your DataModule is not thread safe ; dbExpress, dbGo and FireDac components are not thread safe.  The only way to avoid thread conflicts is by using TUniDataModule, wich implements one DataModule for each concurrent session.

     

    About RichView component: it is the same explanation for other standard VCL components (such as TfrxRichView) : they are not intended to succesfully run in multi-user and multi-session mode.  Your only safe solution is to use UniGui components.

     

    And for your "strange behaviour", once again, it is impossible to reproduce and understand your problem without a test case.

  11. Hi Abaksoft,

     

    According to this article, the answer is no :

     

    No, LiveBindings is not thread safe. The business object property setter, the LiveBindings notification, expression evaluation, setting the property of the destination control/object, and even things like the OnChange event handler for the control are executed in the context of the calling thread that changed the original BO property. But SendMessage is often used in standard and common controls when changing properties that have a visible effect (such as TEdit.Text, TScrollBar.Position and so on) in which case the GUI repaint occurs in the context of the main thread (which processes the message loop).

    What this means is that you might get away with simple scenarios but in most cases you will need to manage the threads carefully. Because the BO doesn’t (and shouldn’t) directly know what it is bound to a simple solution would be to synchronize all threads with a wrapper TBindings.Notify call. Hardly efficient but neither is the necessarily complex LiveBindings system.

    (Jarrod Hollingworth)

     

    • Upvote 1
  12. Hi NightBird,

     

    It is just not possible: you need a full real Windows Server with IIS or Apache and admin access.

    000Webhost gives you only a FTP access with preloaded features (such as PHP or MySQL).

     

    Take a look at contabo.com, it's the cheapest way to get a full Windows 2012R2 Server.

    • Upvote 1
  13. Great idea, and will be very helpful for who are using UniGui or for who want to use it.

     

    we can add more articles.

     

    - Scalability with UniGui.

    - Session Management with UniGui.

    - UniGui vs UniGui Mobile.

    - Using ExtJs commands to overide or extend UniGui Controls

    Good idea, thans Mohammed.

    Feel free to add all articles you want, you just have to freely register to the Wiki.

  14. A DB Connection can not be shared among different threads unless it is designed to behave so.  Each thread must have its own copy of TXXConnection.

    So as a general practice one should not put a connection on ServerModule.

     

    Dear Farshad, you are obviously right!

    Actually, I considered the possibility of putting a TXXConnection on ServerModule, in terms of CPU load and sharing static resources (such as variables)... but I didn't consider at all the thread-safe perspective.   What a shame, what an idiot I am!

     

    So, to be as clear as possible: dbGO (TADOConnection) is not thread-safe at all, dbExpress seems to be able to manage multitthread connections in some specific cases (but it is not recommended in real world), FireDac pretends to have thread-safe Connection, but with so many conditions that, in fact, it is not thread safe at all.

     

    Your conclusion is the only good one: don't put a TXXConnection on ServerModule.  I'll modify the Wiki article ASAP. 

    • Upvote 1
  15. So, both of them are possible : the dbConnexion could be in ServerModule and in MainModule. Is it true ?

    Well, that's not so simple...

     

    As far as I know (but I can make a mistake) : 

    If you put your DB Connection on MainModule (which is recommended), you won't take any risk at all, that is the safest way: everything will work just fine.  But if there are 100 concurrent users, you'll get 100 concurrent connections to your DB: thus your DB server will have to be able to manage such a load.

    On the other hand, if you put your DB Connection on ServerModule, you'll get one, and only one connection, regardless of the number of concurrent users.  So your DB Server will not have to manage a huge set of connections (that can be a good thing if you have a small DB Server): your connection will be shared by all active sessions... but the 100th user could have to wait a long time before getting his slot on the DB Server (that's not a good thing: you'll get some undesirable effects as time-out, blank page, long hourglass time, record lock...).

     

    So, what is the best practice?

    - if your application won't be accessed by many users at the same time, and/or if your DB Server can natively manage a pool of connections (*): you can put your Connection on ServerModule.  Anyway: you can try.

    - in all other cases: use MainModule.

     

     

    Farshad, if I'm wrong, don't hesitate to change/adapt/comment all mistakes you'll find.

     

     

    (*) A TADOConnection + Native client driver on a MS SQL Server is a good example of native pool of connection: SQL Server will create a new connection when needed, without asking to Delphi.  

        A TConnection + ODBC on MS Access is a bad example. 

  16. Editing seems to be open to any anonymous surfer. Isn't it better to limit editing to members only?

    As you wish!

    I just changed this to "publish allowed to members only".

     

    PS: Farshad, you've full admin access to this WikiSpace, you can change what you want!

    • Like 1
×
×
  • Create New...