j_kour

@TokayWell, it doesn't work as expected for some reason. See this: RTTI does not work correctly with TUniForm - General - uniGUI Discussion Forums

I changed this {$RTTI METHODS([vcPublic, vcProtected, vcPrivate])} to this {$RTTI EXPLICIT METHODS([vcPublic, vcProtected, vcPrivate])} and it works now. This directive forces RTTI to ignore RTTI information from the ancestor classes and treat each class independently. The downside is I have to add the directive to every class but it is not such a big deal.

Hi, TUniForm does not pass correct information to RTTI. Say, you have this declaration: type TMainForm = class(TUniForm) private { Private declarations } public procedure sayHi; end; The RTTI code should should reveal all the methods in the class. var fCtx: TRttiContext:= TRttiContext.Create; var form: TMainForm:=MainForm; var rtype: TRttiType:= fCTx.GetType(form.ClassInfo); var gg: TArray<string>; for var method: TRttiMethod in rtype.GetMethods do begin SetLength(gg, Length(gg) + 1); gg[Length(gg) - 1]:=method.Name; end; fCtx.Free; gg array should list all the methods in the class but it misses the sayHi method. Unfortunately, forcing the compiler to inspect all methods using the following directive does not work {$RTTI METHODS([vcPublic, vcProtected, vcPrivate])} On the other hand, if you declare the following class TTestClass = class private procedure method1; public procedure method2; end; and run the same code gg lists method2 (but, strangely, not method1???). I suspect the function that returns TMainForm messes up RTTI. Can anyone think of any work around?

Hi, Not sure if this thread is alive. Can someone confirm that unigui does not ignore attributes. Does RTTI works as in classic VCL?

Hi everyone, It's been a while now since I am trying uniGui and I am very excited about the product. Well done to everyone who has made it happen. I have read the help docs and dived into a good number of demos. I would like to ask a few questions to make sure I understand uniGui philosophy. 1. In a typical client/server app (desktop or mobile) with database, I would use a database pool to connect to the database. In unigui, the docs say that a connection should be added in the MainModule and it will be generated for every new session. So, this means that I do not need a connection pool anymore although a webapp in a specific session can benefit from multiple connections to the database. Is this correct? 2. In large-scale apps, the user should be able to provide the database details on first run. So, is it ok if there is a connection instantiated without full details when a session starts? I would assume that this becomes important on the first database request 3. A typical database set up in enterprise, involves a master database (for writes) and multiple slave databases (for reads). There may also be several microservices running outside a uniGui application that communicate in a typical client/server fashion. A setup like this can be done in unigui? i.e., running a separate server withing uniGui? 4. Can I completely change the login form? delete components, add new UI, etc? 5. It is also typical for the user to see different page on the first run (the setup page) and in ordinary use. How do I achieve this in uniGUi? Do I create a descentant of TUniLoginForm and when the session starts, I change the IsLoginForm property accordingly? Is this correct way to do it? What event would be suitable for this? 6. Unigui manages the life cycple of the forms. So, once a form is created it can be reused. Does this mean that I always need a method to reset the fields in this form, before next use? Thanks a lot. John