Jump to content


uniGUI Subscriber
  • Posts

  • Joined

  • Last visited

  • Days Won


estrify last won the day on January 7

estrify had the most liked content!

Recent Profile Visitors

2255 profile views

estrify's Achievements

Advanced Member

Advanced Member (4/4)



  1. Please take a look to the post where I tried to explain the need for a grid that works in a different way, to be able to do things similar to what other professional products do… Regards,
  2. Thanks for the suggestions but I'm afraid my level of English is so bad that they don't understand me. Let's start again, this time with a list: I don't usually have problems with large data sets because I use profiles, different views, filters, exports, etc. I told you our numbers so you can see that it is very easy to generate a situation with huge records. Only that. So, in some cases, even with all this, a large data set is generated. I did a test with UniGUI and a similar huge dataset in our Salesforce. Salesforce's grid ALWAYS starts displaying the grid in 2-3 seconds. UniGUI grid needs 25-35 seconds. After researching how they can do that, I changed the classic UniGUI gird way of working, making my own paging system and "voilà", the "new conceptual" grid now starts displaying data in 2-3 seconds. This is why I say that UNIGUI does not work well with large data sets. This solution is very fast, and has its own problems and limitations, including the loss of many DBGrid functionalities (infinite scrolling, paging, filters, etc.). This is what I tried to convey to the UniGUI team when I said "what I need", but I see that it has not been understood. I simply trying to explain the need to have a different type of grid for specific cases. Btw, this issue is not specific to UniGUI. The same test in VCL gets similar results, because the main problem is the transfer of information from the database server to the unigui server and the creation of the data set in the latter. Hoping it's clearer now. Regards,
  3. Thank you very much... Please, pay attention to the first point, which is where the most of wasted time (transferring the complete data set over the network): "I think the normal sequence in a UniGUI project is the following: 1. MySQL Server executes the query and returns it to UniGUI server. As I can only use client side cursors with UniGUI controls, this huge amount of data travels from MySQL to UniGUI servers, consuming network resources and time. 2. UniGUI server sends much less amount of data to UniGUI client with a tipical paged DBGrid, so this is done quickly. Filters and sorters of a DBGrid manage temporarily stored data in UniGUI server, so those operations are very fast. "
  4. This is exactly what I do in those cases... What I was trying to tell is that unigui does not know how to optimize communication between database server and UniGUI server for grids when their datasets are very large (as, for example, Salesforce does) ... We all know that no one is going to look in detail into a dataset of 300,000 lines (not even 2000), but the unigui server does not know how to paginate without having the complete dataset, and the problem (for me) is the transferring time that this operation needs. This is what I need to do to simulate what Salesforce does: "To create a custom system to replace a large handful of very useful features of UniGUI's DBGrid: pagination/infinite scrolling, grid filters and sorters. That is, using a DBGrid without paging and implement a totally new paging system doing "SELECT COUNT()" to retrieve the number of rows, use my own controls to do pagination and link it to SQL's "LIMIT OFFSET, ROWS" to retrieve only one desired page. And, obviously, disable all client side filtering and sorting and replacing it with server side filtering and sorting. "
  5. Hahahaha ... As you like ... As I said, only have this issue in very specific moments, when the wonderful design cannot be adjusted to what is requested. Hopefully, you will never have that problem, but the fact is UniGUI grid is far from knowing how to handle large datasets as our Salesforce does. It's possible, of course, but I have to build this kind of grid.
  6. Hi, Please, don't take it as a joke. Depending on the project, it is a more common problem than you might think (may be not with 8 millons records 🙂) In our case, we have tens of millions of installation points, hundreds of thousands of them, we have to migrate their technology between this year and the next, with millions of service control records with its sales, objectives, offers and opportunities. A given operator profile may see a grid with only a few hundred records, but his boss sees a few thousands, and his boss's boss several hundreds thousands, and so on. Thank goodness most high-profile users prefer to see executive summaries, but even so, it's very easy for a given grid to occasionally end up receiving many, many records. Filters initially help keeping record counts "relatively" low, but the problem is that those filters get altered simply because, for example, a manager is seaching for some kind of anomaly affecting hundreds of thousands of installations of which he is responsible. So, the database is our most important tool and its designs is simply critical. In UniGUI, I usually solve the problem by designing different views depending on the profile (usually need about 3 or 4 profile views for a simple project), but it is not the first nor the last time that a profile insists / needs to see the same data as his subordinates, and UniGUI is simply is not ready for it yet. I asked for advice a time ago but without results. Regards,
  7. Hi, One possible solution (with EnableSynchronousOperations=False) : ... private { Private declarations } AllowClose_UniTabSheet3: Boolean; ... procedure TMainForm.UniTabSheet3BeforeFirstActivate(Sender: TObject; var AllowActivate: Boolean); begin AllowClose_UniTabSheet3:=False; end; procedure TMainForm.UniTabSheet3Close(Sender: TObject; var AllowClose: Boolean); begin AllowClose:=AllowClose_UniTabSheet3; if not AllowClose_UniTabSheet3 then begin MessageDlg('Close?', TMsgDlgType.mtInformation, mbYesNo, procedure(Sender: TComponent; Res: Integer) begin if Res=mrYes then begin AllowClose_UniTabSheet3:=true; UniTabSheet3.Close(); end; end ); end; end; Regards,
  8. Hi, try with UniDBGrid1.SelectedRows.Count Regards,
  9. You're welcome... Be careful with UniGUI's access control to files. Don't assume anything: i.e. if you put the file into your bin directory, you can still access it with https://localhost/test.txt or https://localhost/files/../test.txt 😱
  10. Hi, I think it is related with file extension... Rename the file to .txt and you will see how UniGUI will serve it.
  11. Hi, I don't know if this could help: I tried your code with no issues except the need to ensure that the directory exists before the "SaveToFile" System.SysUtils.ForceDirectories(ExtractFilePath(UniServerModule.StartPath) + 'myroot'); Regards,
  12. Hi, Take a look to this topic. It might help. Regards,
  13. Sorry if I didn't understand you correctly. Usually I shutdown the server via the tryicon "Shutdown" option. Other stop procedures are only reserved for errors during the startup of the server. Keeping this in mind, "UniServerInstance.TerminateStandAlone()" works to get out securily of server startup errors (address/port in use, configuration errors, etc.) inside "UniGUIServerModuleException" and "UniGUIServerModuleServerStartup" procedures. I believe that "Halt" or "ExitProcess" are abnormal exit procedures, so they should be used with care. To stop the server via command, in fact "ExitProcedure" is what I do but just in case making sure to previously close all sessions and all backend threads that were active on the server. Due to those threads, if you have them, make sure none of them are still running before "ExitProcedure". One question: how do you remove UniGUI's tryicon?
  • Create New...