Environment:

• Crystal Reports 2008 engine
• IIS 7
• ASP.Net 3.0 page with CrystalReportViewer (CRV) being used to show report passed by parameter

When trying export as PDF (just an example), CRV defaults the name of the file to CrystalReportViewer1.pdf.
Not very nice since associated RPT name is MyVeryOwnReport.rpt and I have many other which I would expect export file at least inherit.

One would expect that Viewer would have a property allowing specify default export name. Not so fast… there is no such thing today exists.

After some head scratching and research, it just happen that Default Export File Name is actually based of the ID property value of the CRV which is still named as CrystalReportViewer1.

Options?

1. Rename ID value of the control as something else. Still, if we use just one page and load reports dynamically, then it would not help much.

   // ReportPreview.aspx file
   <CR:CrystalReportViewer ID="MyVeryOwnExportFile" />

2. Another option is to populate Default Export file name in the code

   // ReportPreview.aspx.cs file
   protected void Page_Init(object sender, EventArgs e)
   {
        ...
       // Load report here
       ...
       CrystalReportViewer1.ID = "MyVeryOwnExportFile";
   }

   It is important to have it set before any code would use it to manipulate a page view state and create references.

3. Trying manually set export options for the Report instance, would not help much unfortunately since viewer would disregard it.
4. Off course there is always an option of coding export functionality yourself and bypass built-in logic…

This concludes another Crystal Reports dance session.

The post How to set default file name for export from CrystalReportViewer in ASP.Net appeared first on Dragonsoft Technology View.

When writing code in .Net some of us take many things for granted and not always keep in mind that many operations are performed in the context of the unmanaged code or in the “old way”…

File operations or legacy code wrappers are perfect example.
Just because library is available as managed code, it does not mean that everything has ability to “self-heal”.
For example in code file is open for edit with lock being placed.
If the file in not closed explicitly, it would be a responsibility of the owner process to release the lock at the time of releasing associated resources – when process is destroyed.

With garbage collection, just because we are no longer using/owning the process/object, it does not mean that it has been destroyed immediately after. GC management core will release object when it “feels” fit, therefore introducing latency into the process.

Off course, proper way would be to be more careful within the code and make sure any locks are released in managed and predictable way: Open/Close, Lock/Unlock, … Easy solution, but not always accessible, especially when working with 3rd party libraries.

So instead, we can force GC manager to “collect garbage” in-place with the following small code:

// See code follow up below
System.GC.Collect();
System.GC.WaitForPendingFinalizers();

What does it do?
First call will instruct GC manager to start the process (1), while second (2) will make sure that we wait for process to be completed.

In the case of the file locks, only after GC has released process which placed the lock in the first place, we can manipulate with the file (ex. delete, rename, move).

The post File locks or when garbage collection goes bad appeared first on Dragonsoft Technology View.

What is Assert or Assertion?

By its definition Assert:

• state categorically
• affirm: to declare or affirm solemnly and formally as true
• insist: assert to be true
• In Computing (wiki): “an assert is a predicate (i.e., a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place”

In general, using assert in the code proven to be useful in many situations because it “checks for a condition and outputs the call stack if the condition is false” and it could help to debug some strange situations in the code.

Assert is your friend

This method is for programmers to use. But what happen often when something is convenient, it started to be used excessively. Why it is happening?

Let’s look at the declaration of Assert in C# (3.x). There are two versions of the Assert(): Debug.Assert() and Trace.Assert(), both in System.Diagnostics namespace.

// Checks for a condition and outputs the call stack
// if the condition is false

[ConditionalAttribute("TRACE")]
public static void Assert(bool condition)

[ConditionalAttribute("TRACE")]
public static void Assert(bool condition, string message)

[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition)

[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition, string message)

As we can see from above code, Assert is to be used for Testing and Debugging and therefore should not be used as a way to present any information to the end-user.

Helping yourself

As useful as it seems, even then Assert infrastructure may not be used to full extend. In the sample declarations above we can see that logic can be invoked with and without providing any additional information.
Imagine how useful is a message “Project raised an Assert in line X” compare to “Project raised an Assert with the Message in line X”.
First option gives you idea where something failed, where second actually tells you what went wrongand where. Let’s use power of the tool-set and provide ourselves with useful information.

Assert is NOT for an end-user

I was asked recently (this seems to be a ongoing discussion) – “Why a programmer should not be using asserts as a regular approach in code conditions validation even when it comes to a production code?”

By default, Assert would show a message box with some information and the current Call Stack. This information, while being helpful to the developer, would not tell much to the user.

With custom TraceListener introduced, message can be hidden from the user and information could be stored, but it is not how it should be used by definition.

If information is expected to be presented to the user in any form, it could be achieved in a form not an exceptional, intended for debugging, situation, but by using regular methods: message box, application log, Windows event log, etc.
Even in the case of component development it is desired to use exceptions (raise/throw) to “bubble” proper message to the error handling layer.

The throw statement is used to signal the occurrence of an anomalous situation (exception) during the program execution.

Assert is a conditional logic

Last, final and probably major concern here is that in Release environment Debug and even Trace functionality would be disabled and therefore, any code/logic which depend on Assert() would be suppressed and all the nice validations became worthless (see declaration above)… and Access Violation errors starting pop up unexpectedly.

The post Assert is your friend… not an end-user’s appeared first on Dragonsoft Technology View.

There are plenty of 3rd party solutions on the market which would help you include some kind of charting support with your ASP pages and WinForms applications – ChartFX, Dundas Chart – these are just few from many available on the market today.

As it turned out, Microsoft has decided to add out-of-the-box support for Charting as well – <asp:chart runat=”server”/>.
Read about it here – New ASP.NET Charting Control: <asp:chart runat=”server”/> by Scott Guthrie – everything you need to know about the .Net 3.5 framework new addition.

For  additional information also visit Alex Gorev’s blog.

Note 1: Even though caption says it is ASP.Net solution, in the original you would find link to WinForms sample as well.
Note 2: Do not worry about Dundas copyright – “Microsoft acquired Dundas Data Visualization Intellectual Property in April 2007.”

The post ASP.Net/WF : New built-in .Net Charting control appeared first on Dragonsoft Technology View.

And the first one is “GetReportParamsAsText“. Very simple but very handy function which allows to include report parameters values in your ASP.Net page without actually displaying the report.
This version works only with Discrete Value parameters. 

/// Function returns list of paramaters descriptions with
/// associated values for specified report
public string GetReportParamsAsText(ReportDocument reportDocument)
{
    if (reportDocument == null) return "Report not specified";

    string result = "";
    string description;
    string valueText;
    ParameterDiscreteValue value;

    foreach (ParameterFieldDefinition prm
                  in reportDocument.DataDefinition.ParameterFields)
    {
        try
        {
            if (prm.CurrentValues.IsNoValue) continue;

            if (prm.CurrentValues[0] is ParameterDiscreteValue)
            {
                value = (ParameterDiscreteValue)prm.CurrentValues[0];
                if (description.StartsWith("Enter "))
                {
                    description = description.Remove(0, 6);
                }
                valueText = value.Value.ToString();
            }
            else
            {
                valueText = "[not supported param type]";
            }

            result += "<strong>" + description + "</strong> " + valueText + "
";
        }
        catch
        {
            // Ignore any errors
        }
    }
    return result;
}

The post Tip: Get report parameters as text from Crystal Reports in C# appeared first on Dragonsoft Technology View.

Since it is not a first time around and appear to be very common situation with dynamic pages, I thought it may be useful to write about it once and then just refer to this post later.

1. We have a table with the following structure:
   

   ID

   ParentID

   Name

2. We also have a stored procedure usp_GetGroupList which would return data from table above.
3. And on our ASP page we have a TreeView control called myTreeView

Few things we are trying to achieve:

1. Small code
2. Minimum of database access

Well, code would not be too complex after all:

private void PopulateTree()
{
    // Populate dataset with data for later use
    DataSet dsList = new DataSet();
    SqlConnection conn = new SqlConnection(myConnectionString);
    conn.Open();
    try
    {
        SqlCommand cmd = new SqlCommand("usp_GetGroupList", conn);
        cmd.CommandType = CommandType.StoredProcedure;
        SqlDataAdapter adapt = new SqlDataAdapter(cmd);
        adapt.Fill(dsList);
    }
    finally
    {
        conn.Close();
    }

    // Clear the tree
    myTreeView.Nodes.Clear();
    PopulateTreeNode(dsList, null, "0");
}

private void PopulateTreeNode(DataSet dsList, TreeNode parent, string parentID)
{
    TreeNodeCollection baseNodes;
    string rowID;
    TreeNode node;

    if (parent == null)
    {
        baseNodes = myTreeView.Nodes;
    }
    else
    {
        baseNodes = parent.ChildNodes;
    }

    foreach (DataRow dsRow in dsList.Tables[0].Select("ParentID = " + parentID))
    {
        node = new TreeNode();
        node.Text = dsRow["Name"].ToString();
        rowID = dsRow["ID"].ToString();
        node.Value = rowID;
        node.SelectAction = TreeNodeSelectAction.Select;

        // Add link back to itself so selected group could be changed
        node.NavigateUrl = "~/default.aspx?id=" + rowID;
        baseNodes.Add(node);

        // Use recusion to populate child nodes
        PopulateTreeNode(dsList, node, rowID);

        // Preselect the node for current group
        if (node.Value == Request.QueryString["id"])
        {
            node.Selected = true;
        }
    }
}

The post Populate TreeView from table in ASP.Net appeared first on Dragonsoft Technology View.

Being somewhat unique in methods declaration for the classes, Delphi requires you to have proper method parameters declaration, but:

1. You do not have to have any default values for the parameters being propagated into implementation section for the method.
2. And you do not have to have any parameters being specified in implementation section at all.
3. If your class implements an interface, then while order and type of parameters remain unchanged for the interface method implemented, compiler would not not even detect it.
4. When declaring the method and then using code complete feature of the IDE, stub generated would have all parameters but no default values.
5. Declaration of the parameters could be “optimized” by changing the way they are grouped if they are of the same type. And sync is not enforced between declaration and implementation.

Convenient. Nice. Easy.

Again, it is convenient since it does not force you to propagate your changes between two if you are to change your default values.

Is default value good or evil?

Well, Microsoft saying it is specific to an implementation of the language (C#) and suggests to use overloads instead. Yes, it can be done, but defaults were introduced for a reason. And, in fact, some compilers, even Delphi, would be confused with overloaded declaration if there is a slight chance of mixing two.

Back in 2005, dflat wrote:

Disadvantage:
1. A bit tedious to call, because even if you don’t put any actual parameters, you have to write down all the types.

Advantages:
1. Unlike C++ default params, this allows all combinations
2. No signature conflict or ambiguity. The whole signature is matched when calling a method with default parameters, because type must be specified if the parameter is missing.
3. No run-time overhead, because everything can be determined at compile time.

Feasibility. I don’t think it’s difficult to implement (in later version of  C#) because:
1. No additional key word is introduced. “default” is already a key word in C#
2. No ambiguity. It doesn’t conflict with any existing C# language semantics

I may sound old fashioned, but I prefer propagate declaration of the method into implementation, because:

1. if for any reason you have to move things around the code, it is convenient to be able grab implemtation of the methoid and easily reusing it in declaration of another class.
2. while reading the code, be able to see exact calling contract for the function you are investigating without a need to jump between declaration and implemtation.
3. also having it in sync, force you to review the code when any default values are changed and if you are using something like XMLDoc/JavaDoc/PasDoc, compiler will force you review your method documentation.

Yes, it “breaks” a “Dry code” principle. But it is not more of “dryness” with that approach then not having any parameters in implemtation section of the method. And while it “polutes” the code, it adds more self-documenting and readability to it.

What are yours points “for” and “against” default parameters and use of them?

The post Delphi, methods and default values. Convenience or contract enforcement? appeared first on Dragonsoft Technology View.