Unit Scope

[eelias]

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

[albertovesx]

I vote for this too.

[Farshad Mohajeri]

Problem here is that though we can add namespace to uniGUI units, there can not be identical unit names because our set of components are totally different.

 

How are you going use same code base when used controls have different properties across namespaces..

[eelias]

Problem here is that though we can add namespace to uniGUI units, there can not be identical unit names because our set of components are totally different.

 

How are you going use same code base when used controls have different properties across namespaces..

 

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