Jump to content
uniGUI Discussion Forums

davidizadar

uniGUI Subscriber
  • Content Count

    35
  • Joined

  • Last visited

  • Days Won

    1

davidizadar last won the day on October 9 2017

davidizadar had the most liked content!

Community Reputation

5 Neutral

About davidizadar

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. davidizadar

    File System Manager (ideas)

    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.
  2. davidizadar

    File System Manager (ideas)

    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).
  3. davidizadar

    UniGUI support, feedback in general and the future?

    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.
  4. davidizadar

    File System Manager (ideas)

    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.
  5. davidizadar

    Richedit (RTF) and HTML editor

    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.
  6. davidizadar

    Communication Peripherals Client

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

    Communication Peripherals Client

    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.
  8. davidizadar

    show form

    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
  9. davidizadar

    UniGUI strong points

    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
  10. 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
  11. davidizadar

    Direct printing can be done like this.

    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.
  12. davidizadar

    Pivot Grid support

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

    Are you more than 40 years old?

    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.
  14. davidizadar

    UniDataModule or DataModule

    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.
  15. davidizadar

    Salvar Foto no Banco de dados "Blob"

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