ZigZig

Maybe a new topic about translation volunteers?

BTW, if You want a French translation of forthcoming documents, I can do that!

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.

Hi Nefasto Cipa, Was it helpful? Does this trick still work?

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.

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

Eid Mubarak from Belgium

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").

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 ?

+1

Could you please post a test case ? I tried to create 5 series with 5 x 300 points. Hiding or showing a serie takes less than 1 second on my computer...

You are right, obviously!

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.

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 : 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.

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.

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.

Davie, 1) Don't use TDataModule, use TUniDataModule (see answers to a previous post) 2) If you want us to help you, please post a test case, as asked in a previous post. Thank you

Done!

Hi Abaksoft, According to this article, the answer is no :

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.

Thank you Hayri Aslan!

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

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.

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.

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!