I installed my custom components package in the RAD Studio XE4
"personality" (both Delphi and C++Builder). It seemed to work fine and
I could create a VCL test app for both Delphi and C++Builder with one
of the components dropped on a form.

But now I am investigating this further and I find that a lot of
components are missing.. :-(

I managed to get the components displayed as a tabbed ribbon across
the top similar to in Delphi7 by going to View/Toolbars/Components.
Then I could also drag it to a place on the screen where it could use
the full width of the IDE.

I then used the > button on the right to scroll through the tabs and
found one of my custom tabs there, but instead of holding 4 component
icons there was only a single one, the other 3 are missing!
In Delphi7 using a package containing the same components they all
show up.
And I have several different tabs in my custom package with other
special components and these tabs are completely missing!

Each component's source file has this style of method code:
{code}
procedure Register;
begin
  RegisterComponents('AGI', [TActiveButton]);
end;
{code}
There are different tab names and type names of course, but otherwise
they look the same. TActiveButton, which is a descendant of TButton is
not shown and I have a number of other modified VCL components too,
which also do not show up.
In fact most of my components do not show!

There should be a "Custom" tab with 8 components, the "AGI" tab with 4
components, an "External" tab with 4 components but they are all
missing!
I tried to use the search for one of the components (EasyListView) but
nothing was shown.

What have I done wrong?

--

Bo Berglund
Developer in Sweden

Did you check the Menu-Component-Install Packages screen if all packages are installed AND checked?

Am 01.08.2013 08:17, schrieb Bo Berglund:
> I then used the > button on the right to scroll through the tabs and
> found one of my custom tabs there, but instead of holding 4 component
> icons there was only a single one, the other 3 are missing!
> In Delphi7 using a package containing the same components they all
> show up.
> And I have several different tabs in my custom package with other
> special components and these tabs are completely missing!

The IDE shows only those components that are usable in the current form 
or datamodule. You cannot drop a TEdit on a datamodule, so no TEdit is 
shown.

The same is true when you switch from design to code view. You cannot 
drop a component into a source file, so no components are visible when 
you edit the source.


-- 
Uwe Raabe
Embarcadero MVP
Certified Delphi Master Developer
Uwe's Blog: The Art of Delphi Programming <http://www.uweraabe.de/>

On Thu, 1 Aug 2013 00:14:40 -0700, Uwe Raabe <uwe@uweraabe.de> wrote:

>Am 01.08.2013 08:17, schrieb Bo Berglund:
>> I then used the > button on the right to scroll through the tabs and
>> found one of my custom tabs there, but instead of holding 4 component
>> icons there was only a single one, the other 3 are missing!
>> In Delphi7 using a package containing the same components they all
>> show up.
>> And I have several different tabs in my custom package with other
>> special components and these tabs are completely missing!
>
>The IDE shows only those components that are usable in the current form 
>or datamodule. You cannot drop a TEdit on a datamodule, so no TEdit is 
>shown.
>
>The same is true when you switch from design to code view. You cannot 
>drop a component into a source file, so no components are visible when 
>you edit the source.

I think you have missed the point....

When I create a new VCL application the first thing that is shown is
the form designer. At this moment I now have components in two places,
the across the screen toolbar similar to what was used in Delphi7 for
example AND now the bottom right corner pane shows a list of groups of
components which mirrors the tabs on the toolbar.

In this list and on the toolbar I find only a single one of the
components contained in my package (the Safenet Sentinel dongle
handler), all other visual and other components are non-existent as
are the tabs where they should be installed.
So I have a single one of my score of custom components available.
And if I use the search function it does not locate any of the missing
components or groups (tabs) either!

The problem is not of visibility depending on context (form designer
must be selected in order to show components), instead it is that
almost all of the components in my package are missing but there was
no indication of this when I built and installed the package in RAD
Studio.

--

Bo Berglund
Developer in Sweden

> >drop a component into a source file, so no components are visible when 
> >you edit the source.
> 
> I think you have missed the point....
> 
> When I create a new VCL application the first thing that is shown is
> the form designer. At this moment I now have components in two places,
> the across the screen toolbar similar to what was used in Delphi7 for
> example AND now the bottom right corner pane shows a list of groups of
> components which mirrors the tabs on the toolbar.
> 
> In this list and on the toolbar I find only a single one of the
> components contained in my package (the Safenet Sentinel dongle
> handler), all other visual and other components are non-existent as
> are the tabs where they should be installed.
> So I have a single one of my score of custom components available.
> And if I use the search function it does not locate any of the missing
> components or groups (tabs) either!
> 
> The problem is not of visibility depending on context (form designer
> must be selected in order to show components), instead it is that
> almost all of the components in my package are missing but there was
> no indication of this when I built and installed the package in RAD
> Studio.
> 
> --
> 
> Bo Berglund
> Developer in Sweden

If you go to Component, Install Components, are you packages showing and are they checked for use?

Edited by: Andy Vines on Aug 1, 2013 2:52 AM

On Thu, 1 Aug 2013 02:53:25 -0700, Andy Vines <> wrote:
>If you go to Component, Install Components, are you packages showing and are they checked for use?
>
No, I have only one package created but it does not show up in the
list and yet the single component is available....
--

Bo Berglund
Developer in Sweden

On Wed, 31 Jul 2013 23:17:33 -0700, Bo Berglund
<bo.berglund@nospam.com> wrote:

>What have I done wrong?

Well, it turns out that while experimenting with XE4 component
installation for dual Delphi and C++ usage I had created a new package
file and added only one of the many components I need to install.
So no wonder there is only one shown....
(bang head hard!)

However, even though I created this using the Wizard and set it to be
installed into a named package, this package was not created with the
name in the list of packages. So it was very hard to find....

Now I have added in all of the components I wanted to use and then I
had to remove 4 because I could not get them past the compiler for
various reasons. Since I do need them I have to come back for advice
on what went wrong and how to solve it.

But I fixed one problem in a few of the components which use the
global DecimalSeparator variable and this apparently has been removed
and instead FormatSettings.DecimalSeparator should be used.
Making that change causes the build to succeeed, but now I have a
problem because we use Delphi7, BDS2006 and Delphi2007 too and in at
least Delphi7 the FormatSettings variable is not defined...

So how can I modify the component source such that it will work for
the earlier versions too???
Is there a conditional I can use to detect the compiler version when
this switch was made???

--

Bo Berglund
Developer in Sweden

Bo wrote:

> I have a problem because we use Delphi7, BDS2006 and Delphi2007
> too and in at least Delphi7 the FormatSettings variable is not defined...

The TFormatSettings record itself and associated function overloads were 
introduced in Delphi 7.  The global FormatSettings variable was not introduced 
until Delphi XE, however it is no more thread-safe than the original global 
variables, so you shouldn't be using it anyway.  What you are supposed to 
do is create a local TFormatSettings variable and use that when needed.  
Since you need to support older versions, you will have to IFDEF the relevant 
sections of code.  The {$IF} directive an the RTLVersion constant where introduced 
in Delphi 6, so you should be fine using them, eg:

{code:delphi}

// D7: RTLVersion = 15.0
// XE: RTLVersion = 22.0

{$IFDEF CONDITIONALEXPRESSIONS}
  {$IF RTLVersion >= 15.0}
    {$DEFINE HAS_TFormatSettings}
  {$IFEND}
{$ENDIF}

{$IFDEF HAS_TFormatSettings}
procedure InitFormatSettings(var Fmt: TFormatSettings);
begin
  {$IF RTLVersion >= 22.0}
  Fmt := TFormatSettings.Create;
  {$ELSE}
  GetLocaleFormatSettings(GetThreadLocale, Fmt);
  {$IFEND}
end;
{$ENDIF}

....

var
  {$IFDEF HAS_TFormatSettings}
  Fmt: TFormatSettings;
  {$ELSE}
  PrevDecSep: Char;
  {$ENDIF}
begin
  {$IFDEF HAS_TFormatSettings}
  InitFormatSettings(Fmt);
  {$ELSE}
  PrevDecSep := DecimalSeparator;
  {$IFEND}

  {$IFDEF HAS_TFormatSettings}Fmt.{$ENDIF}DecimalSeparator := ...;

  SomeFormattingFunction(...{$IFDEF HAS_TFormatSettings}, Fmt{$ENDIF});

  {$IFNDEF HAS_TFormatSettings}
  DecimalSeparator := PrevDecSep;
  {$IFEND}
end;
{code}

--
Remy Lebeau (TeamB)

On Thu, 1 Aug 2013 15:06:07 -0700, Remy Lebeau (TeamB)
<no.spam@no.spam.com> wrote:

>Bo wrote:
>
>> I have a problem because we use Delphi7, BDS2006 and Delphi2007
>> too and in at least Delphi7 the FormatSettings variable is not defined...
>
>The TFormatSettings record itself and associated function overloads were 
>introduced in Delphi 7.  The global FormatSettings variable was not introduced 
>until Delphi XE, however it is no more thread-safe than the original global 
>variables, so you shouldn't be using it anyway.  What you are supposed to 
>do is create a local TFormatSettings variable and use that when needed.  
>Since you need to support older versions, you will have to IFDEF the relevant 
>sections of code.  The {$IF} directive an the RTLVersion constant where introduced 
>in Delphi 6, so you should be fine using them, eg:
>
>{code:delphi}
>
>// D7: RTLVersion = 15.0
>// XE: RTLVersion = 22.0
>
>{$IFDEF CONDITIONALEXPRESSIONS}
>  {$IF RTLVersion >= 15.0}
>    {$DEFINE HAS_TFormatSettings}
>  {$IFEND}
>{$ENDIF}
>
>{$IFDEF HAS_TFormatSettings}
>procedure InitFormatSettings(var Fmt: TFormatSettings);
>begin
>  {$IF RTLVersion >= 22.0}
>  Fmt := TFormatSettings.Create;
>  {$ELSE}
>  GetLocaleFormatSettings(GetThreadLocale, Fmt);
>  {$IFEND}
>end;
>{$ENDIF}
>
>...
>
>var
>  {$IFDEF HAS_TFormatSettings}
>  Fmt: TFormatSettings;
>  {$ELSE}
>  PrevDecSep: Char;
>  {$ENDIF}
>begin
>  {$IFDEF HAS_TFormatSettings}
>  InitFormatSettings(Fmt);
>  {$ELSE}
>  PrevDecSep := DecimalSeparator;
>  {$IFEND}
>
>  {$IFDEF HAS_TFormatSettings}Fmt.{$ENDIF}DecimalSeparator := ...;
>
>  SomeFormattingFunction(...{$IFDEF HAS_TFormatSettings}, Fmt{$ENDIF});
>
>  {$IFNDEF HAS_TFormatSettings}
>  DecimalSeparator := PrevDecSep;
>  {$IFEND}
>end;
>{code}
Thanks Remy!
The components where this is used were created by the developer as
descendants of a couple of VCL components where he handles numeric
input and has to make sure the decimal separators in files are set as
period even though in many countries (including Sweden) it is a comma.
I don't like the way he has done this but the components are used in
the 4 big applications he has written and I have to maintain and the
simplest way is to "fix" the components such that they work and then
forget about it.

But there are also a bunch of formatting functions in a few support
units used by many applications to write floating point data in files
while ensuring that the decimal separator remains as period no matter
what locale the programs run in.
Example:
{code}
function FormatFloatUS(sFmt: string; Val: double): string;
var
  cDec: char;
begin
  cDec := DecimalSeparator;
  DecimalSeparator := '.';
  Result := '';
  try
    Result := FormatFloat(sFmt,Val);
  finally
    DecimalSeparator := cDec;
  end;
end;
{code}
Here the DecimalSeparator is manipulated so the output will contain a
period rather than a comma.
There are other similar such examples....

So by using your suggestion for the solution I can go ahead and make
changes in the conversion units.
I guess I could put the InitFormatSettings call with $IFDEF:s into the
initialization section of the conversion unit and then insert the Fmt
parameter into all formatting calls from there? (With a local Fmt
variable, that is)

Seems like a fair amount of work ahead to XE4-ify the code. Just
started with the components to make it possible to later load the
actual projects and "have fun" making them compile in XE4.
Has to be done though...
--

Bo Berglund
Developer in Sweden

Bo wrote:

> {code}
> function FormatFloatUS(sFmt: string; Val: double): string;
> var
> cDec: char;
> begin
> cDec := DecimalSeparator;
> DecimalSeparator := '.';
> Result := '';
> try
> Result := FormatFloat(sFmt,Val);
> finally
> DecimalSeparator := cDec;
> end;
> end;
> {code}

That is a classic use of why the global variables are not thread-safe.  Imagine 
what would happen if multiple threads tried to use DecimalSeparator at the 
same time, where one thread is expecting comma and the other other thread 
is expecting period instead.  That is why TFormatSettings was created in 
the first place, so threads would not have to trample on each other anymore.

The updated thread-safe version would look like this:

{code}
function FormatFloatUS(sFmt: string; Val: double): string;
var
  Fs: TFormatSettings;
begin
  {$IF RTLVersion >= 22.0}
  Fs := TFormatSettings.Create;
  {$ELSE}
  GetLocaleFormatSettings(GetThreadLocale, Fs);
  {$IFEND}
  Fs.DecimalSeparator := '.';
  Result := FormatFloat(sFmt, Val, Fs);
end;
{code}

> I guess I could put the InitFormatSettings call with $IFDEF:s into
> the initialization section of the conversion unit

No, do not put the InitFormatSettings() call into the unit's initialization. 
 It would need to be called every time a new format/conversion operation 
is performed, as it initializes the TFormatSettings with default settings, 
whih you would then overwrite afterwards, as shown above.

--
Remy Lebeau (TeamB)

On 02.08.2013 00:45, Bo Berglund wrote:

> So by using your suggestion for the solution I can go ahead and make
> changes in the conversion units.
> I guess I could put the InitFormatSettings call with $IFDEF:s into the
> initialization section of the conversion unit and then insert the Fmt
> parameter into all formatting calls from there? (With a local Fmt
> variable, that is)
>
> Seems like a fair amount of work ahead to XE4-ify the code. Just
> started with the components to make it possible to later load the
> actual projects and "have fun" making them compile in XE4.
> Has to be done though...
> --
>
> Bo Berglund
> Developer in Sweden
>

The threadsafe variety of tFormatSettings has been around all the time, 
so if you change to use that, it will be compilable in all versions 
without the use of ifdefs.
-- 
Delphi programmer at Dep.of Nutrition research, Faculty of Medicine, 
University of Oslo, Norway

On Thu, 1 Aug 2013 16:08:26 -0700, Remy Lebeau (TeamB)
<no.spam@no.spam.com> wrote:

>Bo wrote:
>That is a classic use of why the global variables are not thread-safe.  Imagine 
>what would happen if multiple threads tried to use DecimalSeparator at the 
>same time, where one thread is expecting comma and the other other thread 
>is expecting period instead.  That is why TFormatSettings was created in 
>the first place, so threads would not have to trample on each other anymore.
 Got you! :-)

>The updated thread-safe version would look like this:
>
>{code}
>function FormatFloatUS(sFmt: string; Val: double): string;
>var
>  Fs: TFormatSettings;
>begin
>  {$IF RTLVersion >= 22.0}
>  Fs := TFormatSettings.Create;
>  {$ELSE}
>  GetLocaleFormatSettings(GetThreadLocale, Fs);
>  {$IFEND}
>  Fs.DecimalSeparator := '.';
>  Result := FormatFloat(sFmt, Val, Fs);
>end;
>{code}
>
>> I guess I could put the InitFormatSettings call with $IFDEF:s into
>> the initialization section of the conversion unit
>
>No, do not put the InitFormatSettings() call into the unit's initialization. 
> It would need to be called every time a new format/conversion operation 
>is performed, as it initializes the TFormatSettings with default settings, 
>whih you would then overwrite afterwards, as shown above.

Since there is no other use for us of the DecimalSeparator than
switching between comma and period in these functions, could we not
just create two global TFormatSettings variables FmtPoint and
FmtComma, initialize each to the current locale and then set
DecimalSeparator on each to period and comma?
Then we could use the proper one in our formatting functions rather
than re-creating the object each time the function is called.
I think there are places where about a million or so values are
treated to create an ASCII output file with the proper decimal
(period).
But of course we need to find the proper place to initialize them at
the start of our application, that is why I suggested the
initialization section of the unit where they are used.
{code}
unit CommonFuncs;
interface
 ....
implementation
var
FmtPoint, FmtComma: TFormatSettings;
 ....
function FormatFloatUS(sFmt: string; Val: double): string;
begin
  Result := ''; //Default response is a blank string
  try
    Result := FormatFloat(sFmt,Val,FmtPoint);
  except
    //Just to stop any exception from propagating
  end;
end;
  ...
initialization
  FmtPoint := TFormatSettings.Create;
  FmtComma := TFormatSettings.Create;
  GetLocaleFormatSettings(GetThreadLocale, FmtPoint);
  GetLocaleFormatSettings(GetThreadLocale, FmtComma);
  FmtComma.DecimalSeparator := ',';
  FmtPoint.DecimalSeparator := '.';
end.
{code}
This would make sure the variables are local to the unit and
initialized with proper values at start of execution and the calls
would use this setting always thus ensuring that it would work.
We will never modify the properties of the variables anywhere in the
code except in the initialization section.

Should work, or not?

And as the TFormatSettings type was present in Delphi7, wich is the
earliest version we will ever use for any of the programs, I should
not need to use the conditionals either, I think.
--

Bo Berglund
Developer in Sweden