jedidotnet-discuss — JEDI.NET generic discussion list

[JEDI.NET discuss] Input required

[Marcel B. <mar...@xs...>]

All,

to those that have been following my adventures over in the borland.public.delphi.winforms.controls.writing NG (the thread 'A
class is not a class') you will have seen the trouble one runs into when dealing with a run time and a separate design time
assembly. For those who did not follow it, a short (yeah, right!) recap:

<recap>
I have a run time assembly with class X, which has the DesignerSerializer attribute to link the XCodeDomSerializer class in the
design time assembly. The attribute uses the AssemblyQualifiedName (since a run time assembly by convention can never reference
the design assembly directly) of the designer class to connect it. The design time assembly has a reference to the runtime
assembly (the Requires node).

Since the IDE won't be able to find anything that is not in the GAC or in the Assembly Search Paths list (the list you get through
Component|Installed .NET Components, tab 'Assembly Search Paths'), I added the 'jedidotnet/main/bin' folder to that list. That
works (my initial test just spit out a number of comments to show me the contents of the context stack), but as soon as I changed
it to actually write out what it was supposed to write out, I got an 'object reference set to nil' kind of message. After
commenting out everything and add a single line between tests, it all broke down once the value parameter of the Serialize method
(which holds an instance of X) was type cast to X.

Tests finally showed that although the value.GetType type info and the TypeOf(X) type info, seemed identical, there is one major
difference. The <type>.Assembly.Location holds the location from which the assembly is loaded, but for the value parameter it is
empty, while for the TypeOf(X) it was set to the location of the assembly dll.

My initial correction was to use reflection on the value parameter to get the info on the three properties I needed and used the
PropertyInfo structures to actually obtain the value. This works like a charm, but I didn't like the approach at all. After some t
hinking I got the brilliant thought to separate the run time and design time assemblies into two different folders, and only add
the design assembly to the list of search paths. Woohoo, success.
</recap>

Now, what bothers me about this whole change in setup is not so much the additional folder (I can live with that just fine), but
the fact that more problems might be lurking. What really weirds me out is that I have not find any evidence this problem occurs
with the MS provided assemblies (which are all in the same physical folder). Does anyone here know of something I may have
overlooked? The above seems to indicate the run time assembly of the component is recreated in memory, which I assume is done to
avoid the .dll from being locked in case you do a rebuild of the assembly. Is that a Delphi only thing, or does this happen in
VS.NET as well? Is it possible to specify somewhere that the assembly resolver should first look at it's internally recreated
assemblies, before trying to find one in the search path? The types in a recreated assembly do have the exact same
AssemblyQualifiedName values as the ones in the actual file, so it seems .NET is just discarding them as equal because the
Location value differs.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Changed e-mail address

[Marcel B. <mar...@xs...>]

Hi all,

  I have changed ISP and so I have now a new mail address. The new address is mar...@xs... (and please note the dot between
my first name and the b!). The old account will remain active until December 2nd, after that, mails send to that address will
either be lost in cyberspace or end up on someone else's screen.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Update

[Marcel B. <ma...@ze...>]

All,

    I've been working on the Led stuff again (in case you are not subscribed to the commit mailing list; otherwise you already
know this). I updated the region usage and provided description to most (if not all) published properties. In addition I added a
new led style (ShapedLedStyleBase) and the two descendants (SingleColorShapedLedStyle and MultiColorShapedLedStyle). This style
allows any shape to be rendered used as a Led cover. Well, it's going to; opposed to the donated Shape control, the style does not
use a predefined set of shapes but rather uses a base class from which you can derive other shapes. Currently two shapes are
provided: RectangleLedShape and MultiLedShape.

    I suppose you can all guess what shape the RectangleLedShape class renders, but the MultiLedShape is a little different. It
allows you to select a shape (which can be another MultiLedShape), orientation, spacing and count and will result in rendering the
specified shape, the specified number of times either horizontally or vertically.

    The ShapedLedStyle has a CoverHeight which specifies the height the cover extends above the surface. The top and left side
will be a little brighter, whereas the bottom and right sides will be a little darker than the led color, giving the impression of
a 3D cover. The rendering is not trying to be an accurate 3D representation (that maybe looked at later).

    There are a couple of things I want to complete with this unit before I'll release a first alpha version. First of all, there
are still some situations not working properly and the provided control is not much more than a test control that was quickly put
together. That has to be changed first.

    Secondly I want to take a stab at a LedProgress bar. That control should allow a user to provide multiple styles and define
ranges of values, where each range can specify the style and state to use. I don't think a help file will be provided for the
Alpha version yet.

    I also need someone with VS.NET access and check if this thing also works properly in that environment (it should, but I don't
have VS.NET and can therefore not test it).

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Two new donations

[Marcel B. <ma...@ze...>]

Hi all,

  just committed a WinForms Shape control (mimics VCL's TShape control) and a FileOfRecord class. Both were donated by Andreas
Hausladen. I may factor out the shape rendering (especially the rounded rect) to a class in the Jedi.Drawing namespace later.

  I am sorry to report I have not been doing much work on the JEDI.NET (or programming for that matter) front lately. I will
change that ASAP.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

Re: [JEDI.NET discuss] Documentation

[Marcel B. <ma...@ze...>]

> >     I'll be cleaning up the sources of the documentation generation core and it's "test" tool cleaned up and committed later.
> Next
> > on the list is combining the xml files per assembly.
>
>     sources committed.

    they are now. I did add the files, but forgot the mandatory commit action afterwards. I didn't realize that until I committed
a bug fix in the Jedi.Docs.System namespace and noticed the line 'initial revision' in the log window.

    I've been writing some documentation (not much) to see if things were alright. It surprised me a little that for a procedure
it had generated a <returns> section, as I was sure that any method without a return time was not marked as a function. Of course,
.NET methods always have a return type, in this case the System.Void type, so that explained why procedures where marked as
function anyway.

    While checking the Jedi.Windows.Forms.Hmi.Leds documentation skeleton I noticed another nice bug: suppose you have two methods
'OnClear' and 'OnClearCompleted'. The tool would inadvertently place the OnClearCompleted method as a parameter for the OnClear
method. The (reflection) scanner will generate tags as <fully qualified method name>'@'<paramnum><paramname> and I search for
anything that starts with the qualified method name to get the parameters; of course <namespace>.<class>.OnClearComplete starts
with <namespace>.<class>.OnClear and that is not a parameter. So including the @ in the search fixed that problem.

    I've added a feature request in the NDoc forum for Object Pascal support
(http://sourceforge.net/tracker/?func=detail&aid=979662&group_id=36057&atid=416081). Let's see what they think of that.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

Re: [JEDI.NET discuss] Documentation

[Marcel B. <ma...@ze...>]

>     I'll be cleaning up the sources of the documentation generation core and it's "test" tool cleaned up and committed later.
Next
> on the list is combining the xml files per assembly.

    sources committed. Also corrected the timestamp format and the issue where none of the fields where exported (a little to
strict checking whether or not to export will do that for ya).
--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

Re: [JEDI.NET discuss] Documentation

[Marcel B. <ma...@ze...>]

> [...] Soooo, if any of
> you on this list things he's good enough to add that in: please do. When getting the sources of NDoc, you need to look in the
> ndoc/src/Documenter/NativeHtmlHelp2/xslt for the XSL transformations (BTW, the other Html-based documentation outputs also use
> XSLT files, hint, hint).

    no-one? I'll probably be looking at it again soon.

>     I see two options: write a tool to generate/update the xml templates by reflecting an assembly or write a tool to combine
the
> various XML files, translate them and generate the single new XML file. Or does someone know of such a tool (either one of
them'll
> do).

    OK, I have the core stuff for the documentation generation tool ready. It can:

a) reflect an assembly to retrieve a list of types and members (ignoring all those pesky Delphi generated methods and the Unit
class, the unit class should be empty or at least not contain anything public since we do not allow public routines in a unit).
b) generate an empty skeleton based on a) (items that are not required to be documented are generated as a comment; these are
usually inherited methods/properties).
c) if a pre-existing xml file was found during b), the existing texts are merged into the skeleton file (and neatly reformatted as
well; also checks if the text is well-formed XML).
d) if any documented type or member was no longer available, it is moved to a *.removed file (just in case it was because of a
rename and you want to copy-n-paste the texts into the new type/member). Note it will do so only for items that were actually
documented; undocumented items are simply deleted. The removed items are appended to any existing *.removed file.
e) only update the existing .xml file if anything changed (which can be formatting, but I coded such that it will ignore the
timestamp comment when comparing, so no unneccessary changes will need committing to CVS)

    What it still doesn't do:

a) combine the namespace specific .xml files into a single large assembly specific .xml file (needed to get it working in NDoc)
b) perform a check on what sections of the documentation is missing (undocumented params, return values or types/members).

    I'll be cleaning up the sources of the documentation generation core and it's "test" tool cleaned up and committed later. Next
on the list is combining the xml files per assembly.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

Re: [JEDI.NET discuss] Documentation

[Marcel B. <ma...@ze...>]

>
> Maybe doxygen can help?

    the output doesn't look like the .NET Framework documentation. Anyway, I'm already able to generate the .xml file for NDoc
from the assembly (not even that much work, the problems start when you want to combine an existing .xml file with the
additions/changes made in the assembly) so the only thing I need is the ability to have NDoc output Delphi syntax, along with the
C#, C++, VB and JScript languages, which requires adapting the XSL transformation templates.

    thanks anyway!

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Documentation

[Marcel B. <ma...@ze...>]

All,

    I've been looking at the documentation issue. At first I was going for Doc-O-Matic because, well, I know that one and they
have donated free licenses to Project JEDI and it was good enough for JCL, JVCL, Jedi MATH, and Indy (yes Indy uses Doc-O-Matic to
deliver the rtf files to Borland). However, I've been having difficulty in getting the output the way I want to (which is much the
same as the .NET Framework SDK Documentation). So I started looking for other solutions and came across NDoc (http://ndoc.sf.net;
yes, it is Open Source). It generates the output exactly they way I want to, except for one, tiny little detail: it doesn't
generate Delphi syntax.

    Seeing this is OSS, I figured I might take a stab at adding Delphi language support to it. Now, my C# is not the greatest, but
it is much better than XSL Transformations, and the generation of the html pages is done with these translations. Soooo, if any of
you on this list things he's good enough to add that in: please do. When getting the sources of NDoc, you need to look in the
ndoc/src/Documenter/NativeHtmlHelp2/xslt for the XSL transformations (BTW, the other Html-based documentation outputs also use
XSLT files, hint, hint).

    While on the subject of documentation: I wanted to use .uex includes
(http://www.hanselman.com/blog/PermaLink.aspx?guid=e5aebe9b-2bec-493c-bab1-3cbf88f459c1) directly from the source files.
Unfortunately, Delphi XML generation is not following the standard set by MS, in other words: it doesn't matter if I use '///
<include...>' or '/// <summary>' in the source, the resulting XML is just not usable with NDoc (for one thing, Delphi generates a
completely different schema, where it changes the '<summary>' tags into '&lt;summary&gt;' and secondly it generates an XML file
per namespace, instead of one for the entire assembly).

    I see two options: write a tool to generate/update the xml templates by reflecting an assembly or write a tool to combine the
various XML files, translate them and generate the single new XML file. Or does someone know of such a tool (either one of them'll
do).

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Explicit interface member implementations

[Marcel B. <ma...@ze...>]

  Hi there .NET gurus

    C# has the concept of explicit interface member implementations:

---8<--
interface ICloneable
{
   object Clone();
}
interface IComparable
{
   int CompareTo(object other);
}
class ListEntry: ICloneable, IComparable
{
   object ICloneable.Clone() {...}
   int IComparable.CompareTo(object other) {...}
}
Here, ICloneable.Clone and IComparable.CompareTo are explicit interface member implementations.

---8<--

   (the above was blatantly copied from the .NET Framework documentation). Delphi doesn't seem to allow this, so either I'm
missing something or this is really not possible in Delphi (that would be a shame not a real big issue).

    While on the subject of interfaces: I posted this today in QC (#8436):

---8<---
When declaring a class like below, the compiler will issue the hint 'Private symbol CompareTo declared but never used'. This is
wrong, since the method is used by the IComparable interface.

type
  MyClass = class (TObject, IComparable)
  strict private
    function CompareTo(obj: TObject): Integer;
  end;

In addition the following declaration will return a compiler error (Undeclared identifier 'MyComparer') followed by a hint
(Private symbol MyComparer declared but never used).

type
  MyClass = class (TObject, IComparable)
  strict private
    function MyComparer(obj: TObject): Integer;
    function IComparable.CompareTo = MyComparer;
  end;
---8<---

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Final folder structure

[Marcel B. <ma...@ze...>]

    I've committed the final folder structure to CVS. I cleaned up the *.bdsproj files as well. Since Delphi will automatically
add the Borland shared assemblies and the .NET framework folders to the search path, I removed these (since they are not
necessarily the same on your system). In the places where they are used to locate a specific file I reverted to using environment
variables. The .NET framework uses '$(SystemRoot)\microsoft.net\framework\v1.1.4322\' as the path. For Borland shared assemblies I
created $(BDSSharedAsm) to point to the location of all Borland assemblies. This variable is added to the 'Environment overrides'
section in the options dialog.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Issue tracker has been setup

[Marcel B. <ma...@ze...>]

    Just a quick note to tell you that the Project JEDI issue tracker now also has a JediDotNet project. The issue tracker can be
found at: http://homepages.borland.com/jedi/issuetracker/main_page.php and will be categorized on assembly name, with two
additional categories ('Examples' and 'Help and documentation').

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JVCL Help team coordinator
JEDI.NET team coordinator

[JEDI.NET discuss] Inline collection editing

[Marcel B. <ma...@ze...>]

Hi all,

   just committed to CVS in the dev/jedi_mbe folder the changes in Jedi.System and Jedi.Collections to allow editing of collection
items from within the Object Inspector (PropertyGrid). It allows adding, editing and deleting of items. Note that I currently only
checked collections containing items with a default property (not yet tested what happens when you have a collection of Integer)
and only IList type collection, not IDictionary.

    I also committed the update Jedi.Windows.Forms.Hmi.Leds unit to use the inline collection editor (technically it already did
but it had to be adapted to the changes made to the editor).

    Note that those with anon. access to CVS may need to wait a few hours before the anon. server is updated. You'll need rev 1.2
of all three files.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JVCL Help team coordinator
JEDI.NET team coordinator