eelias

Eventually yes... We are moving to a multi platform world as you know... However there is a benefits to offer mixed possibilities. There are thing that I only can do on Desktop right now. I mean, almost everything can be done on web also, but there is not all components available. IN this sense I expect a way to create uniGUI components from javascript packages and that can be used on the delphi way, pretty much what you doing with EXT-JS, Like graphs, if we could have a nice graph package, from one of those many javascript options, well there is TeeChart javascript but not sure how complete it is. Speed and integration with other applications is better on desktop. There are a lot of desktops around. And depends also in how the application is done. Web is easier to deploy, but a no installation app is easier also. Download run and it knows where to connect via web (I am using XData). I see web as a alternative, at office the user will follow the destkop option. But at home or when traveling it can use the web version. Very handy. However what I see happening on my country (and you have a lot of Brazilian programmers, since it is one of the biggest comunities) is the small/medium cloud based ERP, that you have a company account and you use the back-end features. Then in the front-end you have the POS/store functions. It is a mixed used. The web is better for deployment, you create new version and deploy quickly. The front-end changes much slower. So, I see a great future for UniGUI, I am counting with it. Thank you.

Sorry I cant !!! The Business pack is about Aurelius ORM (kind of NHibernate) and RemoteDB, DataModeler, Scripting... those are all non-visual stuff that I use. I am not using DBComponents anymore, those are simple but I cannot get my application running on firemonkey. My goal is to have the same app in all the platforms: web, desktop and mobile. It is possible, but not simple... Today I have compiled successfully for the first time my application to run on android. The same one I have running on UniGUI. File size: 50 MB !!!!! Long road to deal with it.....

And just giving another example: B4A: it is a compiler for android... US$50,00 (3months subscription) ONLY or US$100,00 (2 years subscription) they have more than 25,000 users active on the forum, kicking in! Delphi (or AppMethod) : Hundreds of dollars: everyone complaining, few people buy, in my country huge piracy. So what? Spread the technology and get more people involved with good price. Ext-js is already too high for that, but .... Hard to say.

Well.... I am sure the guy up there does not know what is saying... speaking in Euros and not in Dolars that was used over the forum... However look this: Delphi XE5 license Brazil: US$1,500.00 TMS Business Pack: US$ 1,000,00 ElevateDB with source: US$800,00 EXTJs: US$329.00 UniGUI: who knows??? Considering half of this price per year as updates. IT IS NO CHEAP ! There are benefits? Yes, based on these tools I have customers. But it is not a river of money. Sorry, I had to say that after this 2 post.... have a nice day!

+15

using with XE2 up 4 and XE5 up 2 no problems at all with the latest UniGUI.... However recommend using with XE5 everything seems faster, specially the IDE

Sure! I am not against any adopted model, I just care about the future of UniGUI, since I am each time more basing my projects in it. RIght now they are small projects, but at sometime they can get big and the future of the FMSoft is based on the model selected... Selling is a model used for ElevateSoft, TMS, DevExpress and they are doing well, follow their concept... But I see people asking for open source it, however I do not believe that ALL that are asking for that is going to be involved... It is just a way to get the source code and keep going and pay nothing. Keep the good work

The app that function better is the one that was correct designed. I know thousands of old looking bad designed application either... and new ones... I just cannot advocate that just because is the old style is better. No it is not. Based on that concept DOS like applications are much better. In very few situations I could agree with that, but that was because BAD design. And after 25 years of experience with pascal, and since delphi 1 I see programmers that only want to deliver fast and with no care about the result, in that case the old style helps a little on the data entry, nothing else.... however, keep the good work, I am fully supportive to your tool and want to be extensively supporting it, just keep an eye on the future Eduardo

Well, according some researches this is programmers opinion, not the end user opinion. Sure at the end of the day the user needs its work done, and that case visual is not the main importance. BUT I just got a chain of stores to use my software because I have exactly the best of both worlds... I use advanced flat interface and intuitive data entry keyboard enabled... the software that they use and is changing by mine is actually a old looking windows 3.1 style... so based on my experience I cannot agree with you. What I see is that a lot of lazy programmers do not invest in doing better. There is need to study and invest time in doing better. Sure! I like those DB controls, but those are not my focus... nothing against it.... just preference... I wish uniGUI can work both ways Like I said, this is not that many are saying and going... actually we are each time more distant of this kind of interface. We are going to a multi platform world were web will definitely play the main role and native cross platform applications. Touch will be more and more used, but new metro like applications does not mean that you cannot use it for heavy data entry. Good to know that extjs 5 will have all that... hope to get hands on that soon !! I have some concern on this style thing, and I believe that uniGUI needs to be flexible to go both ways, this was my intention. On Microsoft C# world you have those options, you can be extremely simple or be more elaborate. It is fantastic that UniGUI permit to have JS injection! than it let me do more things that was not in the scope. I just suggested to have more integration with extjs, not today, but across the versions...

Zilav, Like you said it is subjective. I can tell you that there also millions of users that like MetroUI also. And for Line of Business application it is extremely good visual. For other uses I don't like either. My interface are not just panels with colors, but they are animated, those tiles have movement. And overall application try to mimic other metroUI style. Sorry to tell you but each time more windows 3.1 Delphi 1 looking applications will be less and less used. Are you going to hold this position and be one of the last programmers to move to better looking applications? UniGUI is a great tool, and I like it and adopted it because it is stable flexible. But just said that from interface perspective it is simple, there is nothing wrong on saying that. If you ask anyone here you will see that the more elaborated interfaces you need a lot of panel etc. Eventually this is the only and correct way and I am asking too much... I am sorry for that. But I believe we could have more things on the Delphi side and do depend on JS injection. I want to see uniGUI each time better. Thanks for your comment. My reason of the post was to comment about the n-tier strategy that I was asked.

Farshad, I hope you take in a good way... I am missing a much better way to style things, from the perspective of a Delphi programmer. Since it is directed to a Delphi programmer... Like the styles on VCL/FMX. I know there is CSS from the extjs, but again, I will be going to the other side and adding complexity to the project, but I prefer to a solution that could be maintained by a Delphi programmer in the Delphi side. Take a look on StyleBook of FMX as example, I dont want to rely on extjs templates/styles For me it is not important DB components so much.. .since I am preferring to use LiveBindings. However if we could have more of the ExtJS properties implemented on the uniGUI components much better, to not rely on JS injection to control ExtJS. For example, transitions, animations, etc I see that many applications are going to web, and they are using solutions that permit to write the web-style. Delphi desktop looking is not web-like and soon will be considered not acceptable for web. This the menu and one of the many forms on the application running in uniGUI: http://snag.gy/gM3My.jpg http://snag.gy/XCznZ.jpg I use animations and other effects to looks like more web than desktop application. I believe the result was not far from expected, but it took me a lot of effort, writing a complete set of components and handling the colors. In that that sense, reducing the difficulties to make more like web would be great!!! Here is an excellent example: http://designmodo.github.io/Flat-UI/ Eventually I am not aware of some of the possibilities of UniGUI, however this Flat UI is an example of looking that is expected today. uniGUI is already doing a great job on the structural part. It is time to go to design part, and web is all about visual! Thanks Eduardo

Nefasto 7. I used since beginning UniGUi as web only. I was aware it could be used for desktop (the reason of its name) and I was aware that Farshad could eventually change that. But I was not followin that change. I dont care about UNIGUI in Desktop. I think it is wrong doing both. 10. I understand you. But UniGUI needs to be something. Right now it is a wrapper around EXTJS and missing a lot of its features. UniGUI needs to get an clear identity. Is it going to keep extjs? so implement all of it at delphi side! No need to JS code injection at all. That will even permit on the future to change the extjs without breaking the delphi side code! Right now is a mess... part of the code is delphi, and part is JS injection. To solve that I have create my own set of components deriving from UNIGUI, to isolate my code from uniGUI, if some day I need to go to another framework I have decoupled from unigui, I will suffer less. All my JS injection is part of my components. I dont use it on my source. "as a side note, I don't think that deriving uniGUI components from VCL or Firemokey can make much difference, since the features you see in web mode are entirely made from scratch using server side computation or javascript" You right also, however delphi programmers understand better VCL, and ExTJS is basically a VCL. ExTJS is not a trully web concept. They tried to adapt the desktop to the web. Not sure that is correct way to go. On the IDE side there is a need to design the form, so at minimun you need to descend from TComponent and implement TPersistent. So at least you have a base common. So if you are going to keep ExTJS you have a lot of common with VCL/FMX, so why not inherit from the same base classes? (like it is today, but I advocate that it should have a way to use scoping)

"Hi Eduardo, I am trying too with TMS Aurelius + Databinding + Dependency Injection (Spring4D) + VCL. I am trying to create some basic structure that allow me to increase the development time and in a future with uniGUI. But I really feel a little lost because I haven't see any reference. I'm just a begginner trying to grow up but it's not easy. So, I really will thank any help or oriantation about it." I will give the answer in the public forum so others can have benefit of that. I got many help from others here also Delphi is known for the RAD structure, that is: You put a button on a form, click on it and start writing code right there. That is fantastic to create a prototype. No more than that!!! sure.... I have made several big projects with Delphi, and all those I made using this RAD stuff caused a lot of problem after some years. WHY? because you start doing COPY and PASTE of the code everywhere or moving to places that was not correct. The fact is that RAD is not OOP oriented. And it is not Procedural oriented either... The better way now is to go OOP and using the RAD resources. For OOP I am using TMS Aurelius. There are other like mORMot and tiOPF that are FREE. However TMS Aurelius is extremelly simple, since it is client side. mORMot is powerful, but it work with a different concept that is server side OOP repository. Aurelius permit that you create classes that will be persisted on a database. So you dont open a database and look for a table and a record. You use your class. It is needed to follow the demos and read about how Aurelius work from their documentation it is not difficult, but it is different. Right now It changed everything for my project: I dont have database oriented project anymore. I can use ANY SQL server that is available (the main ones) and dont care about this detail. There is no more fields references on the code anymore. That is terrible, since if you change the field name on the database you have no idea where in the code the field is. With an ORM (like Aurelius) you change your class, and during compilation you will know where the impact will be. And more than that. Based on class you can deal with details of the field. For example, in my country you change ZIP code like this: 99999-999, based on a class I can check the consistency of the data before it gets persisted. That is the same thing for any data, one place with all the intelligence. The other thing is using a Framework for Layers. The best structure for Delphi to use with UNIGUI is MVP. Here is a simple example with no framework: http://www.danieleteti.it/category/programming/design-patterns/mvp/ There are other patterns, but I liked MVP more that the others: 1 - M : Model this is where you place the classes that deal with the entities. Entity is the class that will be persisted on the database. The model has the business model. It means that it keeps the intelligence to use the classes correctly. The Model is a class and you should have one for each main concept: TModelProduct, TModelCustomer. The TModelProduct will use and understand how to deal with TEntityProduct, TEntityStock, TEntityPrice for example... and keep them all correctly. When learning Aurelius for example, it will make more real this. But do not follow the examples of Aurelius !!! They choose MVC model that is hard to use on Delphi. Take a look on the examples and compare with the Link above of MVP. 2 - P: PRESENTER The presenter is a class that know how the model works and how the view works. This is the code from behind the Form. Everything that you put here, came from the Old RAD stuff, any button any event, anything that you used to create on a form is placed here. Doing that will make you create in a general way and the view can be changed. 3 - V: View The view: this is the form itself. My forms now are totally dumb, no code at all. Only drawing, components, and LiveBinding. LiveBinding is difficult at first time. I am still experimenting that on uniGUI. and if neded I will be using old DataSet style. AUrelius comes with a DataSet component that makes the magic and make the classes compatible with DB components. My Presenter asks the Aurelius manager for a cursor that can be assigned to the TAureliusDataset and it behave like a table. That is fantastic because you can change the Entity classes, that will reflect on the tables and keep everything working. It is important to understand this structure based on the Danieli Teti example from the link. The View SHOULD NEVER know about the presenter. That is what Dependency Injection is all about. A pattern to how make things dependent of each other. Spring4D is one full featured framework for that. BUT if you learn design patterns you will understand that you can write that by yourself. I told before that UNIGUI should be only for web. No VCL unigui components AT ALL, just for design time only and with no need to be 100% working at design time. I believe Farshad should put all his efforts in make it everytime better on web. Right now it is good (there is no other real option) but it is TOO SIMPLE! and TOO SIMPLE on VCL either. So, the worst of both platforms, that is no GOOD! Writing an application you should use the best of each platform. IN a MVP pattern you can do that: you create your Mode, Presenter, both used in all the platforms. Same code. No references to platform specific things: Never use TUniPanels, TUniLabels, TLabels, TPanels or anything that is platform specificl. You can use low level classes, that is one thing good about UNIGUI since descend from the same classes that FMX and VCL. That low level classes are safe to be used. But even better, look at the Daniele code and see how to be totally isolated. In uniGUI we need to use the grid that is available. But in VCL you can use TMS Grid or DevExpress GUI, MUCH BETTER ! However you can find a javascript GRID light years better and want to use it, if you use MVP pattern you can on the UNIGUI project use that and it will not cause problem on the other project. The fact is that you need to draw a view for each platform. My current platform have 3 views for each presenter: - WEB: based on unigui: I use the components that unigui give me and I use javascript ones. I try to use the best possible, I dont have the concert to make UNIGUI works on desktop, I am free! - Desktop: I use FMX: it is a lot different, you need to learn LiveBindings, but in XE5 the bus are mostly fixed and they simplified the LiveBindings. FMX only if you have XE5, before that is hard with FMX then you should go VCL. Why FMX: I am using because I need to get ready for Apple and need to get experience for mobile. - Mobile: I have a view for each one, one using DPF components for android, and other using DPF for IOS There is need to do that, then you get the benefits of each platform keeping the intelligence of you code protected by the other layers. It took me a lot of time learning and getting rid of the bad addiction of RAD. It is important to read and practice this patterns also: http://delphipatterns.blog.com/ Eduardo

I know this is old post, but I needed to reply: 1. there are lots of open source projects. Just look for it. Many are big ones and even complex. For example: - mORMot: ORM framework for Delphi. Very complex and extremelly powerful. The Leader of the project is making a lot of money out of it with consulting. - DPF Native Android Components for FMX (there is of IOS also): a huge set of native components to be used on Android based on FMX (A lot more components than uniGUI) - tiOPF: another ORM framework for Delphi, a lot of people using it - CyComponents, many really great components actively updated - Indy: you use on uniGUI it is Open Source! - I could list many and many more, but just for take an idea. 2. Open source does not mean that you dont get money of it (see VirtueMart history for example) 3. The problem is "old thinking" that does not permit to change the model. 4. I am not against any mode, commercial or open source. The problem is when the progress is too slow. uniGUI is great and I am liking. But in more 2 years everything made in uniGUI will be considered OLD. IN th current progress how long will take to update it? 5. A mixed model could be create, there are companies doing that. MANY. Open source for the basic (entry level) and paid for more advanced stuff. The things is to bring more programmers to the community to help the project grow fast. 6. The concept of UNIGUI is now phasing out. Embarcadero is pushing Firemonkey. VCL will be around but it will each time more less interesting. To have an Uniqui GUI with a framework that is not the main focus of Embarcadero anymore not a good option for a project that remains in BETA. 7. UniGUI should go for Web ONLY! and create a way to share a common base for unit scoping like VCL and FMX before version 1. It is MUCH BETTER to have 2 forms created, one for UNIGUI other for Desktop (FMX/VCL). 8. Delphi RAD is basically WRONG !!! Let me explain: I use delphi since version 1. I used the RAD way, that uniGUI also advocate somehow. That was a BIG MISTAKE. We need to separate code from the Form. The Form should be isolate from the rest. Then we can recreate the form in different frameworks without breaking the business logic. this is MVP/MVC style, that the rest of the world is using.... UniGUI should follow this pattern, of course, can let the lazy to learn guys using the RAD style that will kill them someday.... 9 New structures like LiveBinding should be considered. Much better (of couse now in XE5 after many bugs fixed) than VCL, because it permits doing more. For basic database connections is more complicated, but when learned you can do more..... 10 UNIGUI should keep attention to other web frameworks, and decouple from extjs. This is more difficult, and should be considered for the future, but put all the dices on the EXTJS not good. There are MANY java developers angry about how extJS is slow... and looking for alternatives. There are several FREE alternatives. UniGUI should be decoupled of the web framework, eventually creating its own. I dont like the Raudus way, but the only thing nice about it is that it has now its OWN web framework. But I do not advocate doing t hat, since there are many open source javascript framework. 11. Embarcadero still pushing that Intraweb trash because there is no real option for them. Embarcadero will not embrace EXTJS, because there is fees. If that change and UNIGUI turn to be WEB only and more directly compatible to FMX/VCL based on unit scoping I trully belive they will ask UniGUI to be part of the Delphi product, that is good for Farshad. So, this is my point and only post this because I DO CONSIDER WITH GREAT KINDNESS THIS PRODUCT AND WHAT IT SUCCEED. Eduardo Elias

Bresler, This is my first time on that. I have started using Aurelius recently and is amazing. Much better working with ORM with classes than doing direct database access. I will never go back. Data-binding I have not test a lot, but it works. There are some posts with solution for that. I have created a complete set of components directly inherited from the UniGUI ones, so any need I can implement what is missing. BUT if that cause any problems (since I am only on the beginning of this project, Aurelius provide a DataSet component that can be used in the regular way) I am not using RAD style anymore. This is the Delphi way, but i see now it leads to terrible code and too difficult to maintain projects. I am using MVP pattern and isolating totally the GUI, so forms that are totally dumb. This way I only need to redraw the form for each project. I have a project right now that works on UniGUI, Firemonkey in Windows and Mac and Firemonkey in Android (not tested in IoS, but should work). I had to draw 3 times each form, one for unigui, one for desktop app one for mobile app. Aurelius plays an important role on all that, since my data layer is much more intelligent now, based on classes. Removing code from the Form layer. At some point I will share the experience on the forum. Eduardo

John, I use DBISAM for many years, I am now sticking on version 4.27. (with Delphi XE2) It just works very well. Always. I could not solve this problem of Row Mismatch. There is something on the way events are triggered by ungui on the many layers until it gets to DBISAM. My solution was to completely avoid editing on grids. There is only one place that I remain using the grid editing, but the users are told that this eventually happens, so I have not got further, It depends on how the user clicks on things... there are users that never get this. I dont know... I am now going to other solutions with UniGUI, so not sure if that will happen again, I will be using TMS Aurelius + DataBinding + SQLite, so I expect to at least different issues Sorry cannot help Eduardo

Farshad, compare unigui with vcl/fmx and you see that you have the same number of differences and similarities. VCL/FMX are different in many things, but there are a lot of basic shared functionality. Thinking that way you give less problems to the programmers that need to share codebase. You will be better positioned on the market if get closer to the current framework, and unit scoping is the way for that ! example: unit sharedunit; uses forms; myform := TForm.Create(Self); This simples snapshot can be the same in FMX and VCL because the unit scoping. It can be the same for UniGUI also ! My suiggestion is to create a new set of units that will translate the current ones to unit scoping support. then you have: UNIGUI.Forms : uniGUIForms + uniGUIFrames TUniForm - > TForm TUniFrame -> TFrame and so on, in all other units and components. It will be up to the programmer to take care of the differences, but you are giving this way a HUGE help for that happen. The only thing is that the programmer need to put on the project options -> delphi compiler -> unit scope names: UniGUI and create a project for each platform, one for VCL other for FMX and other for UniGUI (this is what I am doing) and sharing of code will be much more possible. Of course is not 100%, I have some specific platform units, but those are few. The main source code is the same, and using MVP patter it is even better. And do not forget: FMX will replace slowly VCL. It will take many years, but you need to pay attention on that. I hope I was clear, I belive that for you is not that difficult to make this new set of units renaming what you have today and getting compatibility. I offer my help on that, testing, coding etc. (This is the direction I need in my code, but i am using just a small set of UniGUI) so we can get closer to FMX/VCL based on unit scoping. Thanks.. Eduardo

I would like to suggest a change on the unit names of uniGUI. I am writing an application that will use Firemonkey, VCL and Unigui, all based on the same codebase. If the unigui units could be changed accordingly it would easier to have more compatibility. The example comes from FireMonkey and VCL. There is FMX.Forms and VCL.Form. If you use only "forms" in the uses clause, the compiler will use the definition on the project for scope. If project is FMX it will use FMX.Forms, otherwise VCL.Forms. That could could be nice for UniGUI. Instead of uniGUIForm it could be UniGui.Forms. Then I can have my base code define for 3 different frameworks. Of course there are differences, but taking a look how FMX/VCL is, you will see that there is compatibility on base class up to TComponent, I believe is the same thing for UniGUI. That helps a little. I have not take too deep my thinking on this, because I am right now trying to understand how to have the same code base for FMX/VCL/UniGUI. I dont want to use uniGUI controls for Windows desktop, I want to use only for Web. Not sure are this time you could change that, eventually making a different package to rename the units and classes. Thank you

That did the trick. Thank you !

I am upgrading my projects to XE5 In Delphi XE2 everything was working on 0.93 I have installed a new VM Box with Windows 8 32 bits with Delphi XE5 (no updates yet) I have used 0.95.0.1045 that I downloaded today. I went thru all the setup and it got installed. I have oned the MegaDemo project for test it and when compiled give the following error: [dcc32 Fatal Error] uIdHTTPServer.pas(55): F2051 Unit uniGUIApplication was compiled with a different version of ExtHTTPServer.TIdExtSession There is very few other components installed. The first one I have installed was UniGUI then all others: ACBr Aurelius210 cyComponents6.60 paxcompiler_v3-2_05mov13 TMS Component Pack 7.1.3.0 ZEOSDBO-7.1.3a-stable I have unistalled unigui and reinstalled all again (as the last) and the same problem persisted. What should I do? Eduardo Elias Library Path: $(BDSLIB)\$(Platform)\release;$(BDSUSERDIR)\Imports;$(BDS)\Imports;$(BDSCOMMONDIR)\Dcp;$(BDS)\include;C:\Dev\Components\Aurelius210\Source;C:\Dev\Components\Aurelius210\library\dcp\Win32;C:\Dev\Components\Aurelius210\library\bpl\Win32;C:\Users\Public\Documents\RAD Studio\12.0\Bpl;C:\Users\Public\Documents\RAD Studio\12.0\Dcp;C:\Dev\Components\ACBr\Fontes\ACBrBoleto;C:\Dev\Components\ACBr\Fontes\ACBrBoleto\Logos;C:\Dev\Components\ACBr\Fontes\ACBrBoleto\Logos\Colorido;C:\Dev\Components\ACBr\Fontes\ACBrBoleto\Logos\PretoBranco;C:\Dev\Components\ACBr\Fontes\ACBrCapicom;C:\Dev\Components\ACBr\Fontes\ACBrComum;C:\Dev\Components\ACBr\Fontes\ACBrConvenio115;C:\Dev\Components\ACBr\Fontes\ACBrCTe;C:\Dev\Components\ACBr\Fontes\ACBrDiversos;C:\Dev\Components\ACBr\Fontes\ACBrDiversos\ACBrFalaWaves;C:\Dev\Components\ACBr\Fontes\ACBrGNRE;C:\Dev\Components\ACBr\Fontes\ACBrLFD;C:\Dev\Components\ACBr\Fontes\ACBrMDFe;C:\Dev\Components\ACBr\Fontes\ACBrNFe2;C:\Dev\Components\ACBr\Fontes\ACBrNFSe;C:\Dev\Components\ACBr\Fontes\ACBrPAF;C:\Dev\Components\ACBr\Fontes\ACBrSAT;C:\Dev\Components\ACBr\Fontes\ACBrSEF2;C:\Dev\Components\ACBr\Fontes\ACBrSerial;C:\Dev\Components\ACBr\Fontes\ACBrSintegra;C:\Dev\Components\ACBr\Fontes\ACBrSPED;C:\Dev\Components\ACBr\Fontes\ACBrSPED\ACBrSPEDContabil;C:\Dev\Components\ACBr\Fontes\ACBrSPED\ACBrSPEDFCont;C:\Dev\Components\ACBr\Fontes\ACBrSPED\ACBrSPEDFiscal;C:\Dev\Components\ACBr\Fontes\ACBrSPED\ACBrSPEDPisCofins;C:\Dev\Components\ACBr\Fontes\ACBrTCP;C:\Dev\Components\ACBr\Fontes\ACBrTEFD;C:\Dev\Components\ACBr\Fontes\Imagens;C:\Dev\Components\ACBr\Fontes\PCN2;C:\Dev\Components\ACBr\Fontes\SintegraSultan;C:\Dev\Components\ACBr\Fontes\synalist;C:\Dev\nahar\naharCore;$(fmsoft)\uniGUI;$(fmsoft)\uniGUI\uIndy;$(fmsoft)\uniGUI\ExtPascal;$(fmsoft)\uniGUI\CSSParser;$(fmsoft)\uniGUI\SynEdit\Source;$(fmsoft)\uniGUI\Dcu\Delphi2015;$(fmsoft)\uniTools;$(fmsoft)\uniTools\Dcu\Delphi2015 Browsing Path: $(BDS)\OCX\Servers;$(BDS)\SOURCE\VCL;$(BDS)\source\rtl\common;$(BDS)\SOURCE\RTL\SYS;$(BDS)\source\rtl\win;$(BDS)\source\ToolsAPI;$(BDS)\SOURCE\IBX;$(BDS)\source\Internet;$(BDS)\SOURCE\PROPERTY EDITORS;$(BDS)\source\soap;$(BDS)\SOURCE\XML;$(BDS)\source\Indy10\Core;$(BDS)\source\Indy10\System;$(BDS)\source\Indy10\Protocols;$(BDS)\source\fmx;$(BDS)\source\databinding\components;$(BDS)\source\databinding\engine;$(BDS)\source\databinding\graph;$(BDS)\source\data;$(BDS)\source\data\ado;$(BDS)\source\data\bde;$(BDS)\source\data\cloud;$(BDS)\source\data\datasnap;$(BDS)\source\data\dbx;$(BDS)\source\data\dsnap;$(BDS)\source\data\Test;$(BDS)\source\data\vclctrls;$(BDS)\source\data\datasnap\connectors;$(BDS)\source\data\datasnap\proxygen;$(BDS)\source\DataExplorer;$(BDS)\source\DUnit\Contrib\DUnitWizard\Source\Common;$(BDS)\source\DUnit\Contrib\DUnitWizard\Source\Common\dunit;$(BDS)\source\DUnit\Contrib\DUnitWizard\Source\DelphiExperts\Common;$(BDS)\source\DUnit\Contrib\DUnitWizard\Source\DelphiExperts\DUnitProject;$(BDS)\source\DUnit\Contrib\DUnitWizard\Source\DelphiExperts\DUnitProject\dunit;$(BDS)\source\DUnit\src;$(BDS)\source\DUnit\tests;$(BDS)\source\Experts;$(BDS)\source\indy\abstraction;$(BDS)\source\indy\implementation;$(BDS)\source\indyimpl;$(BDS)\source\LiveTile;$(BDS)\source\Property Editors\Indy10;$(BDS)\source\soap\wsdlimporter;$(BDS)\source\Visualizers;$(BDS)\source\xtab;$(BDS)\source\DUnit\Contrib\XMLReporting;$(BDS)\source\DUnit\Contrib\XPGen;$(BDS)\source\data\rest;C:\Dev\Components\Aurelius210\library\bpl\Win32;C:\Dev\Components\ACBr\Lib\Delphi\LibD19

Thread-safe is a good reason. Speed I don't see a problem. However GDI handles its a problem. Thank you in let me know.

I am speaking about uniGUI. I dont want to switch to any other framework.

Erich, Thanks on answering. I believe I was not clear. I am not looking for showing PDF at all... I am looking to use any VCL component, like grids, like diagrams, etc, in a "passive" mode. Since unigui is based on extjs what we really see is the extjs. There is no real VCL control, they are only for design. That is fine! However one of the good things about delphi is the huge amount of components. And we could get benefit of that if standard VCL could be rendered inside a special control, like a panel that you drop the component inside it. When it updates itself, this special panel takes a picture (snapshot) of the current canvas and send it as jpeg to a correspondent panel in the client side (unicanvas or uniimage) Did you get the idea? The problem is that I am not sure what is involved on let the standard control draw in canvas. It sounds simple, but could be a lot of trouble. Eduardo

I do understand how uniGUI works, however I was thinking about some cases where there just simple cool libraries like TMS where complementary components could be used. I was thinking on the component render its graphic to the canvas (as vcl does) and then somehow send the canvas (as a jpeg) to the client side. It could have a component that could facilitate that, so once the VCL component is done, canvas is updated, it get it and send to be displayed on the client side. Of course the client side will only see a snapshot. But that is a lot better of not having ANYTHING! In many cases for example, could be possible to use TMS GRID or DevExpress GRID and only get its snapshot. (it will looks like a report basically). For other cases like TMS Diagram Studio, it could be nice to send the resulting diagram. On design time it will be created and used as plain delphi component. It will render the results normally and the snapshot when done sent. Eventually it could be a container? Like a Panel that anything VCL that is placed inside will be rendered and sent when done or streamed like video (frames/second that could be defined since web could be slow) (i am pushing a little here)? That would open a door for the huge amount of components out there to have some presence on unGUI. Eduardo

Get the latest version and go for each one of the demos. There is no formal documentation, only the demos and the forum. And the forum is much of the time very specific problems. Open them and test. When you see one that does not show anything in particular, go for the component properties and events, because there are some javascript code that is in the component properties. Mega demos is one good to see. Everything in one place. The rest, you have to try and ask here! good luck. Eduardo