davidizadar

Probably, this code should work: for Index := 0 to FTreeView.Items.Count -1 do FreeAndNil(TNodedata( FtreeView.Items[ Index ].Data ) ); FTreeView := nil; You surely defined TNodedata, and created each assigned Data, so that it is your responsibility to release them. FTreeView is of type TUniTreeNode, which implements an interface. It should be enough to assign nil to it to trigger its Destroy method.

HyperServer should grow to HyperServer Farm with Load Balancing. Current HyperServer is enough for many applications, but if the application must serve many clients, one node will not be enough As soon as there are several HyperServers, server affinity, load balancing, keeping truly global sessions will become issues. It is something like what happens with RemObjects DataAbstract and RemObjects SDK Olympia. A Run-Time Designer will solve many of the issues raised by many people. It could allow modifying an existing design or creating a visual design from scratch. As this component will execute at run-time, it will allow seeing what the customer will see. This fact will solve all the issues related to setting the correct properties for achieving the perfect alignments and any other visual properties. It should be possible to save the design (*.FRM) for loading it at run-time or use it for adding it to the original project. In this case, it will be possible to define Delphi events for server-side event handling. If desired, despite loading the design at run-time, it could be possible to capture client or server-side events (in Delphi or using some scripting language). Server Module shared repository Some application tasks or memory structures are global and shared between sessions. While in current UniGUI it is the developer responsibility to create and administer the access to these structures, when having multiple instances of an application, under a HyperServer or in a Server Farm with multiple HyperServers, UniGUI should provide some additional support to make it easier and standard. This kind of global repository should provide a messaging infrastructure with point-point, broadcasting, publisher/subscriber, etc. making it easy to create real-time (chat) applications, offline messaging, etc. Marketplace Free or paid components I have a dream (I'm not Malcom X) about components like those used in electrical designs. I'll add more details later... A few examples of possible generic solutions packed as database schemas and components: Role-Based Access Control (RBAC) Explicit class-to-entity mapping in the database (supporting inheritance, logging, versioning, deep copy for complex objects, dynamic classes, generic annotations) Workflow Designer and Workflow Engine (with roles, work lists, statistics, chains of approval) Responsive Design I didn't add this feature explicitly because it should be part of the Designer (mentioned as the second feature). The Designer could be used at design-time or run-time. Whatever is created could be saved as a .DFM to replace the previous design or to override it at run-time. If no scripting is needed, or if the code is already available as actions in a data module, it should be possible to keep the design only run-time. If there is no way to code something required for the form, the design should be further developed at design-time. In any case, the responsive features should be defined in the design, Delphi-style, with more options than just the client-side JavaScript code.

In this first post I want to suggest a few things about this process. It is not enough to make requests, but to try to justify it, what will bring the feature to the UniGUI ecosystem. There are two quite different kind of requests. Some concrete feature or improvement to solve a current issue, or a big feature to make UniGUI become something much better than now. I'll focus on the latter kind of requests. It is important to have some feedback about our proposals (and not only from Farshad).

I have been working with Farshad from time to time since 2011 because of some huge projects I migrated from the Windows desktop to the Web. More than that, use frequently brainstorm about the product and the best way to serve its users. Farshad is not the only developer working on uniGUI, but he is the creator and architect of the product and takes care of the core development. Other developers build on top of the core framework fantastic components like the Google Maps integration. Nevertheless, it is true that Farshad has been taking too long for fixing some issues (some of them, not because of their complexity). This year he faced a few personal hurdles which made him slow down and the backlog kept growing. It didn't help that the 2019 RoadMap was very ambitious. The truth is, he is trying to close the year with some important features and fixes to take advantage of the holidays for pausing and recovering. The next year will be challenging, Until now, uniGUI was developed as the foundation for creating web applications, Delphi-style, and not as s vertical solution for some specific kind of application. After working with uniGUI in several projects, I arrived at the conclusion that uniGUI could include a few additional features targeting enterprise applications. For example: Role-Based Access Control - Almost every medium or large application requires fine-grained access control at several levels (database, services, user interface). The difficulty here is to cope with different databases without depending on an external ORM and offer a simple user interface that could be customized by the user. Run-Time Editor - Some enterprise applications need to be flexible enough to add more information than initially required, and to be able to redesign the user interface according to the user roles or personal preferences. It is something that was already done several times, but it should be flexible enough so that the user could select where to store the modified DFMs. This kind of development could be done by everyone, not just by Farshad. I'm personally interested in creating a few of them, but other developers could do the same. I hope that other members of the forum will help to improve uniGUI by making suggestions, requesting fixes or improvements, or just sharing scenarios where uniGUI didn't provide all the tools required for creating and delivering a solution. I really need to know what are the pending issues with the most negative impact on your current development. As someone mentioned before, having new features is important, but any blocking issue should have a higher priority. Regards, David Izada Rodriguez

Hi everyone, This post has two parts: A complaint about the development speed of uniGUI (and about the transparency about its progress) Alternative solutions like TMS Web Core Your complaint is valid because the progress in uniGUI development slowed down this year (good reasons or bad reasons, it doesn't matter). Also, the Roadmap 2019 was very ambitious and it was affected by the slower speed. You are right on this point. The second point is not right for most of the developers using uniGUI. Let me explain why (before I get lynched without jury or trial). The main goal of uniGUI is to bring the power of a Delphi desktop application to the web and doing so while preserving what makes Delphi one of the best RAD tools ever created. Some people could be smiling now but let me mention a few things we take for granted in Delphi: Visual form designer with property editors and under-the-hook links to data modules containing datasets, action lists, and all kinds of events (no need for pesky MVC,/MVVC, or any other over-complicated and over-engineered tools except pure and clean Delphi). Data grids that get linked at design time and just work. Clear separation of the user interface and the business logic using forms and data modules. Any common application requires a database and if you need a scalable application, you will need a good middle tier for connecting to it and managing the connections from multiple clients. This scenario was always a problem for client/server applications written in Delphi because each one of them used a data module for its connection, but so did every other client. Products like RemObjects DataAbstract were created for solving this issue. With uniGUI, you get your server which holds that data module and DataAbstract becomes a luxury you don't really need. As soon as HyperServer runs as a Server Farm, you will be able to handle as many clients as your server infrastructure can handle. On the other hand, you can have all your code in JavaScript and that doesn't mean that your application can scale, it is just that you will need to create your own server and manage your connections. I could expand my answer, but it should be enough. My last comment is that TMS Web Core is not the only "alternative". Even the old IntraWeb is trying to create a "revolution" by over-promising, under-delivering, and trying to reinvent the wheel. All these products are years behind what uniGUI currently offers. We want more, we want everything! But just try any of the alternatives and you will see the difference. As a parting gift. Last year I was requested to develop a relatively simple application but using IntraWeb plus CGDevTools. After a few days, I finally discovered that they didn't have modal forms and the tricky solution they offered only worked for simple pop up messages. It took me a couple of weeks to create a generic solution that worked "almost" like a modal form. Another week to discover that none of the dataset events were really supported by their grids and that my assumptions were wrong about being capable of working Delphi-style. In the end, I learned a lot of idiosyncrasies about the product, deliver my project, and became convinced that IW + CGDevTools (including jQuery) was a waste of time. Anyone is welcomed to repeat the experience... Sorry for the rant. David Izada Rodriguez (old, very old Delphi developer)

You are right. The documentation needs an update.

Access to local files is limited by the rights of a browser application. When uploading files, the browser allows you to select a file using its own dialog. When downloading files, the browser will allow you to select where to store the file and assign a filename. Any other solution will require an HTML 5 API for local file system access. That kind of API already exists for Google Chrome, but I don't know of a standard version implemented in every browser.

The two new components giving access to the virtual server file system should use properties like the uniGUI ServerModule, providing defaults for common locations and allowing for custom locations (like a config folder).

Guys, Have a little faith in Farshad. We are working very hard to finish a complete product (as bug-free as possible, scalable, documented, with a good installer). Farshad has already a few surprises to announce and the migration to Sencha Ext JS 6.5.3 and HyperServer are finished. He will address all your concerns very soon and I hope that many of you will be happy. Just wait a little longer.

Introduction In typical desktop client/server applications, every reference to files is always local (including shared network locations). These applications use OpenDialog and SaveDialog everywhere and the meaning is always clear. In uniGUI applications, when we use the OpenDialog we could be trying to open a local file or a server file. When we use SaveDialog we could be trying to download the file or to save it to the server. In addition to the distinction between local and server, we also need to know if the file in the server will be temporary, local to the user, or public and accessible to everyone. What is needed? We can not use OpenDialog nor SaveDialog as both components are for the VCL. OpenDialog This dialog allows to select the file we want to open, but the result is just the file name. We still need to load it. We can replace OpenDialog with the UniGUI component TUniFileUpload. The component allows defining the Caption of the dialog and the filter to use when browsing for the local file to be uploaded. The button Upload will request the upload of the file to the server. When the upload is finished, the component will trigger the event OnCompleted passing a parameter of type TFileStream which should be saved to the server. SaveDialog UniGUI does not include a component equivalent to SaveDialog. SaveDialog allows the user to select the location of the file to save while saving it must be done by ourselves. In a web application, hosted in a browser, when we download a file, the browser will ask for the destination or it will default to a predefined location like Downloads (it will depend on the browser's configuration). uniGUI offers several options to start the download: 1. UniSession.SendFile( ServerFile ) 2. UniSession.SendStream( TStream, LocalFile ) 3. TUniMemo.Lines.SaveToFile( ServerFile ) In this new scenario where we have two locations, client and server, the previous methods are not enough. OpenDialog - Server Most of the time, OpenDialog is used for selecting a local file and working with it. It could be a .INI file, .TXT, .DBF, anything. We need to find out what is the correct use case: the file could be used for some specific operation. It will be temporary. For example, when importing a .DBF file as part of some EDI process. In this case, we should save the file to the user area in the server, process it, and delete it once it is not needed anymore. we could be opening a file which should be part of the server storage, just for the user or shared among all users. The uniGUI component cannot be used for this. We will need to implement a component which will receive from the server a TUniTreeView with the file structure for our public/shared folder and the user's folder. This new component will replace the OpenDialog when we know that we need to reference files on the server. This component should expose a similar interface to the current OpenDialog. For a temporary file needed on the server, we could use the temporary location provided by uniGUI (UniServerModule.TempFolderPath). SaveDialog - Server As with OpenDialog, using SaveDialog could have different use cases: Sometimes we need to export some information from the database to a local file we will take with us. Here we could just download the file In other occasions, we could be saving something to use it for some other purpose by our application. For example, export some information from the database to send it by email. This scenario will require creating some component to allow browsing the server folders (public, and the user's folder) to mimic the current SaveDialog. If the file will be temporary, it is also possible to use the temporary folder provided by uniGUI (UniServerModule.TempFolderPath) Conclusions We need to implement two new dialogs to be used as replacements for OpenDialog and SaveDialog, but making reference to public and users folders in the server. Part of the implementation will be to expose our own public path and user's folder in our ServerModule. Our file system structure will look like: Root temp files public users <username1> <username2> ... log Both OpenDialog and SaveDialog should expose the public folder (and any subfolders) and the specific user folder associated with the session.

Some time ago I was working on a migration of an application from the desktop to the web using uniGUI. The application used a TRichEdit control and stored the information in a database. The new application, web-based, needed the documents in HTML and I started working on solutions. I found a few tools which could convert RTF <=> HTML. Some of them are: Subsytems – Expensive, but it does the job unRTF – GNU DocFrac - Sourceforge Html2Rtf - DLL for both HTML -> RTF and RTF -> HTML My idea was to use the database events OnBeforePost and OnBeforeScroll to execute the conversions while keeping the database format as RTF (to keep compatibility with the desktop application). I never implemented the solution but it could be used by anyone interested in moving from RTF to HTML.

As I mentioned before, there are many web applications communicating with local or remote hardware by using a central server and local services. Most of the modern Security Systems migrated or are migrating to the cloud without losing features. David

Hi guys, I see this question everywhere, not only in this forum. A desktop application has full access to the local resources (depending on the user rights, of course), while a web application runs in a sandbox inside the browser. It is not possible to access local resources without creating a huge security risk and it is necessary to find other ways for executing some previous tasks. Let's use a practical example to make things clear. Imagine that you want to implement an Access Control Security System hosted in the cloud. It is the kind of system where the users identify themselves at secure doors using proximity cards or biometrics like their fingerprint. At some point, each user will have to be enrolled in the system, a reader will have to scan the fingerprint or read the proximity card number. Sometimes you can use special-purpose readers which you can attach to a PC USB port. In other cases, you can only access the readers through the network. In any case, if the web application is enrolling one user, we want to enter the personal information and link that person (the cardholder) to some specific proximity card or to his/her own fingerprint. So, you will want to press a button "Read Card Number", swap or tap the reader with the card, and show the card number on your form. The local desktop application will directly read from the USB port and get the card number. The web application requires something different. Basically, all these "integrations" will happen server-side. If you need to read proximity cards in the enrolling stations, you will create a Windows Service which will be running in the background connected to the back-end server through a web service. By polling that server, the service will know when it needs to read a card, it will wait for the swipe or tap, get the number from the USB/COM port, and send it to the server. The web application will also have a timer which will refresh its data looking for the card number stored in the database. This kind of application, the Windows Service running on the local PC, and the web service hosted on the server and connected to the common, central database, is easily done using products like RemObjects SDK or just plain Indy (TCP or UDP). Just remember that the client PC connects to the remote server through several security layers, firewalls, routers, etc. It is easy to reach out, but it could be impossible to get in. You can always ask for something and receive a response, creating a two-way communication channel which will always start with the client, never with the server.

Depending on the Delphi version you are using, you could get the class of the form using its ClassName as a parameter. The solution, using RTTI, is in StackOverflow David

Some time ago I started creating some demos showing how to migrate from Delphi VCL to uniGUI. You can find some of them in BitBucket David

Creo que hay una confusión en la discusión. Farshad no recomienda que se creen aplicaciones serias amontonando todo en un formulario. Eso iría contra casi toda recomendación moderna de programación. Aunque no se estuviera programando con una estricta separación de la interfaz de usuario y la lógica del programa, estaríamos creando algo difícil de mantener al mezclar diferentes tareas en el mismo código. Una aplicación para el Web, con o sin uniGUI, es inherentemente multi-usuario. A cada usuario o cliente remoto se le asigna una sesión (representada en el código por el MainModule) y todos sus recursos deben depender de ella. Si se crea un formulario, la función que se encarga de crearlo lo hará en el contexto de su sesión y lo mismo sucederá con los módulos de datos. Es obvio entonces que la manera segura de crear la aplicación es con formularios y módulos de datos bajo control del framework. Si se decide crear los módulos de datos On-Demand, opción disponible ahora en uniGUI, cada vez que se abra un formulario que necesite un módulo de datos, la referencia que hará al cargarse el formulario se encargará de activar la creación del módulo de datos. Si se quiere garantizar que ese módulo de datos, privado para ese formulario y sesión, no exista la próxima vez (con datos anteriores) bastará con liberarlo en TUniForm.OnDestroy. Es bueno recordar también que el Delphi, desde la versión 4, ofrece varios mecanismos para facilitar la separación de la interfaz de usario de la lógica de negocios. Básicamente, se puede usar controles de datos y acciones (TAction con los eventos Execute y Update). Disculpen la parrafada, pero una herramienta poderosa no garantiza la calidad del producto final. Todo depende de cómo se use. David

There is another solution: Your uniGUI Server is anywhere (local or in the cloud). Your clients are anywhere. Your printers are anywhere, but you can install an agent with access to one or several of them. This "agent" is usually a Delphi application running as a Windows Service (or on Linux) with access to the server environment hosting the uniGUI Server. The idea is to use the server environment, a central database server or even the server file system, for requesting the print jobs from the web application and use the agents for printing the PDF files. A correctly designed application will allow registering printers, handling permissions, queuing jobs for specific printers. The same approach applies to interactions with local hardware like USB devices.

Yes, it is planned. Sent from my Pixel 2 XL using Tapatalk

57, started with ALGOL-60 on PDP-8 clone, FORTRAN IV, BASIC, assembly (8080/8085/Z-80/6805), IBM-360 assembly, PASCAL, Microsoft Pascal for IBM PC, Quick Pascal, Turbo Pascal, Borland Pascal, Delphi (all of them), Stonebrook Pascal, UCSD Pascal, C/C++/Turbo C/VC++/Visual Studio, C#, all kind of SQL (Informix, DB2, Sybase/MSSQL, Oracle 8.3 and higher, MySQL, Paradox, dBASE II/III/IV, FoxPro, Clipper, Visual FoxPro, DataEase. Despite Borland, Delphi is still alive, but it is no longer appreciated for what is worth. Delphi plus products like Spring4D, DUnitX, Devart (UniDAC and EntityDAC), TMS (a whole bunch of good products like Aurelius), DevExpress, and now uniGUI makes the perfect tool for solving all kind of problems. Licensing costs and the false perception about its "imminent" death are the only drawbacks.

Sorry for the delay. Sessions are explicitly closed or they timeout. In both cases, the session will be terminated, all the managed resources will be released, but you will have to release any unmanaged resource.

It is possible, but it is specific to the data access technology (ADO, FireDAC, etc) and database (MSSQL, Oracle, MySQL, etc). If you are using FireDAC, you can find several examples on the Embarcadero Wiki.

Gustavo, the right question is if you should create a managed or free data module. When you create the data module using the uniGUI Wizard (DataModule), the data module lifetime will be managed by uniGUI. It will be created automatically at the beginning and released when the user session is closed. If you choose to create a common data module, you will be responsible for creating and releasing it. You will find both types of data modules on the Hybrid demo application.

The original design of Delphi always allowed to drop data controls everywhere. But any medium-sized project doing that quickly becomes unmanageable. The recommended design was always to use the form for visual components and the data module for data controls (and other non-visual controls). Delphi used to create applications only for Windows, but now uniGUI can create applications for two different platforms, making the previous recommendation almost a requirement. Now, if your application is very small, tiny, you can put all your data controls in the MainModule and you will be able to identify everything. If that is not the case, every form could have its own data module (except if it is just something visual, which is highly improbable). The only current advantage is the fact that managed data modules will be created on-demand and released by the session. The code will be clear, easy to understand, easy to modify, and it will take advantage of future features of uniGUI.

Adding scripting to a project should be (and it is) totally unrelated to the platform. If you look at the latest Best Practices, with uniGUI with can target both platforms - desktop and touch - and it is possible to separate the user interface from the business logic. Basically, we should leverage Delphi actions and event handlers for moving all the business logic to a data module. Any piece of code in the data module is just Delphi code and it could be implemented by using a scripting language. The only requirement is to provide the bindings (the script must be able to reference the host application classes). You can use Pascal Script, paxCompiler, anything. Things become more interesting when you add a run-time Form Designer to the mix, allowing you to redesign (or just design) the user interface, save that design, and load it again everytime you activate it again. Everything is possible!

When you create the form, you pass UniApplication as the Owner. As you can see in the MainModule, the function locating it at run-time is: function UniMainModule: TUniMainModule; begin Result := TUniMainModule(UniApplication.UniMainModule) end; In your form, you have access to UniApplication: Self.UniApplication So, if you need to access the MainModule, use: TUniMainModule(Self.UniApplication.UniMainModule)