Nightly news, 13 May 2011

Another week, another pile of documentation to write! Fortunately, the code mills are still grinding away, bringing you another week’s worth of features and fixes through the nightly builds.

WPF Diagrams

  • Force based layout algorithm now supports layout algorithm info
  • Fix for cursor visuals sometimes misaligning to the grid when zoomed in
  • Improved integration with the Visual Studio designer property grid
  • Changing the Zoom property programmatically or through binding now zooms around the centre of the viewport
  • We’ve added some shiny new demos. Very snazzy. Check them out.

LightSpeed

  • Filtering a view no longer causes Visual Studio to think the diagram file has changed
  • Improved logging of code generation exceptions for the benefit of those people who go round deleting their templates. No names, no pack drill
  • Fix for an issue with Distinct().Count() when counting a projected member of a joined table
  • Added support for traversing associations via a through

Phone Elements

  • Smallest and largest data point now always displayed even when sampling charts with very large numbers of points
  • Fixed an issue where the legend item template was not applied when adding a data series to a chart in code rather than XAML
  • “Tiny bug fixes.” Hey, that’s what it says. (My favourite commit comment this week, though, just says “?” but I think that’s just a Victor Hugo tribute.)

WPF Elements

  • Fixed an error when adding a data series to a chart in code rather than XAML
  • Added ChartAxis.TitleVisibility property
  • Improved handling of ChartAxis.LabelLevelCount for zooming and panning
  • Added ChartAxis.LabelStep property
  • Added support for displaying a single point of data when ActualMinimum equals ActualMaximum
  • Minor stripiness tweak to ChartGrid
  • Fixed a FormatException in ChartAxis
  • The “tiny bug fixes” from Phone Elements

Silverlight Elements

  • Fixed an error when adding a data series to a chart in code rather than XAML
  • Fixed an issue where the legend item template was not applied when adding a data series to a chart in code rather than XAML
  • Added ChartAxis.TitleVisibility property
  • Fixed a FormatException in ChartAxis
  • DataSeries.Visibility can now be used to collapse individual series on a chart
  • Let’s hear it one more time for the “tiny bug fixes”

Free editions of nightly builds are available from the downloads page, and retail editions from the store.

5 Responses to “Nightly news, 13 May 2011”

  • Thanks for the latest build of LightSpeed! This time I had no issues with the libraries themselves, but the installer seems to have a couple of glitches. It hung up calculating the amount of space needed for the install, but continued on with a bit of prompting and installed itself just fine.

    I’m still waiting for the feature that lets me describe a one-way relationship, so I don’t have to keep manually modifying the generated Model.cs file every time I make a change. Any idea when that will happen?

    Thanks again for a superb product!
    Dave

  • It seems I may have spoken too soon. The code generated by the latest libraries is different form the code generated by the last one I was using successfully, released May 2. Many of the [System.Runtime.Serialization.DataMember] decorations have disappeared, and some have been added where there were none before. No big deal, but now I get an InvalidDataContractException, stating “No set method for property ‘CreatedBy’ in type ‘HawkModel.AssyLine’.”

    This may be intentional, as I know you had plans to improve the way these fields are handled, but I can find no reference to a pertinent change in the blogs anywhere.

    Has there indeed been a change in the way these fields are populated? If you are populating these fields form the library code somehow, is there any way to control what value is used to populate them? In a situation where LightSpeed is running as part of a back end web service, there has to be a way to communicate who the actual user is, right?

    I will back out to the May 2 release until next week, as I know you all are on the weekend already, and wait for clarification before I try to upgrade again. Ahh, the joys of beta releases!

    Dave Newman

  • Hi Dave,

    Yes, there has been a change in the way we emit DataMember attributes, to allow user control over which properties and associations get included in the serialisation graph. It is now controlled by the Generate Data Member Attribute setting which defaults to true for properties and false to associations (which was the previous hardwired behaviour). However we should not be emitting it for load-only properties. For the time being you should be able to get around the problem by setting Generate Data Member Attribute to False for your CreatedBy property, but we will get this fixed for you. Thanks for reporting it!

    Regarding one-way relationships, if you set the Collection Name to an empty string, then you will get a one-way relationship. You will need to mark the other end of the relationship as Cached, so this is currently suitable only for reference-data-like scenarios where e.g. a Person has a relationship to a Country but you do not want a Country to have a collection of all its People.

  • OK, so I finally got things to work as I think you intended. I had to shut down all copies of Visual Studio, remove the current version of LightSpeed, restart Windows and install the latest build of LightSpeed. When I restarted VS and loaded the solution, I finally was able to see the new Generate… properties. Whew!

    However, you state above that Generate Data Member was previously hardwired to False for associations. I beg to differ. After rebuilding the model.cs file with the latest build, it seems like ALL my associations quit working. If the Associations are non-Data Member by default, you get no relationship by default, and related records don’t get loaded or saved.

    From what I am able to tell, Associations were generating the Data Member Attribute by default, i.e., that property was hardwired True. What I was doing prior to this release was commenting out the few that I did not want to have that behavior (effectively forcing that property to False).

    Now it seems you’re telling me I need to set the Generate Data Member Attribute to True for every association I want loaded? I can do that, but it is most definitely NOT what was happening before.

    Please clarify,
    Dave

  • […] note a commit comment consisting solely of the character “!”, nicely rounding off Victor Hugo Tribute Week here at Mindscape […]

  • Leave a Reply

Archives

Join our mailer

You should join our newsletter! Sent monthly:

Back to Top