License

Hi, I have a most irritating error or bug (?) in GoDiagram.
When opening my view the first time in my application everything looks fine (see view1).

Then when I close the view and the reopen it I get the “… for evaluation only…” text in the upper left corner of the view (see view2).

I do have a license which is set to Northwoods.Go.GoView.VersionName
property.
The same problem appears if I open and display two views at the same time.

Need some help here.

That seems odd. Does it work if you set VersionName each time before you create a GoView? (I’d try it myself, but it is the weekend…)

I do it in the constructor, see below (where nnnnnn is my license number).

namespace TeklaGraph
{
public partial class GraphControl : UserControl
{
public GraphControl()

{
Northwoods.Go.GoView.VersionName = “TeklaGraph?nnnnn”;
InitializeComponent();
this.BackColor = Color.Lavender;
this.Dock = DockStyle.Fill;
}

Is this the right place to do it ?

  • Jake, no hurry, enjoy the weekend…

I think you want it in App initialization, before the constructor to the control is called.

Hi again,
well, it did not work. Maybe I should try to explain the situation:

  • The GoDiagram control has a C# wrapper to implement all UI etc. The C# wrapper is in turn a control which is used in a C++ view (complied with /clr). The view itself is part of a separate DLL.
    The solution today contains 19 different projects wherof 11 is separate DLLs and the application itself keeps “everythin together” by sending lots of messages to the different DLLs due to the users actions.

I do not know if this concept may have something to do with the “evaluation text” which is displayed in the reopend view. I’m not quite familiar how Windows handles OCX controls but it seems that the GoDiagram control “looses” the VersionName information from the second time the control is created.

I’ve tried to set VersionName both in the C++ code before calling the controls constructor and also in various places in the C# code, all without success. The same result in both Debug and Release versions.
Does not feel good if the end users will see this “evaluation text” when the system is deployed.

Today we have sunny weather in Stockholm
Smile

The prefix (TeklaGraph) has to be the calling assembly’s name… is that always true in this set up?

Hi Jake, thanks for your time.
I think I mentioned sometime before that I am not (yet) so good at C#. Maybe I use the wrong C#-term in some places but I’ll try to explain the concept in more details.

The actual GoView is implemented in a C# class library named TeklaGraphLib. TeklaGraphLib is a separate assembly. A part of the code looks like this:

namespace TeklaGraphLib

{

public class OptoGraph : GoView
{
pulic OptoGraph()
{
this.AllowLink = false;
this.DragsRealtime = true;
this.Tool = this.DefaultTool = new WheelZoomingTool(this);

This OptoGraph class is used as a UserControl in an other C# class library named TeklaGraph which is also a separate assembly:

using TeklaGraphLib;
namespace TeklaGraph
{
public partial class GraphControl : UserControl
{
public GraphControl()

{
Northwoods.Go.GoView.VersionName = “TeklaGraph?nnnnnn”; // License for GoDiagram
InitializeComponent();
this.BackColor = Color.Lavender;
this.Dock = DockStyle.Fill;
}

The OptoGraph class is instantiated in InitializeComponent as:


private void InitializeComponent()
{

this.optoGraph1 = new TeklaGraphLib.OptoGraph();

}
public TeklaGraphLib.OptoGraph optoGraph1;

I’m sure you know all about how this works.
So, if I understand it right, the TeklaGraph assembly is the caller of the OptoGraph (GoView) and the VersioneName should therefore be correct.

Now, the GraphControl class is used in a C++ CWinFormsView (I don’t know about your skills in C++, but if you where part of developing the GO++ “in the old days” then you are really good). Microsoft MSDN Online help describes the class like:
“MFC uses the CWinFormsView class to host a .NET Framework Windows Forms control within an MFC view. The control is a child of the native view and occupies the entire client area of the MFC view”

The constructor of CWinFormsView takes the typeid of the control as an argument:
CXOGraphView::CXOGraphView() : CWinFormsView(TeklaGraph::GraphControl::typeid)

So, everytime the user opens a new C++ view (in my case a CXOGraphView) the chain of constructors and setting the VersionName should be correct.
I really hope we can solve this problem because the GoDiagram is so much faster and better than the old GO++ I have an other view in my solution which uses the GO++ heavily and is the next to be replaced with the GoDiagram.

As princess Leia in StarWars once said:
“Help me Jake, you are my only hope”

I did write the original GO++, but that project was started in 1983… it’s been a looooooong time since I looked at C++ code.

The “assembly name” is the name of the .DLL.

If “TeklaGraphLib” is really the assembly name, you want TeklaGraphLib?nnn. But that wouldn’t explain why it works the first time.

Question: you purchased almost a year ago… was this working until recently?

If you can put together a small sample app that shows the problem, I can do some work debugging for you, but I’m guessing there’s no way I could reproduce this issue from scratch if I tried.

Jake, it hasn’t been that long: 1993, not 1983.

Hi, no it should be TeklaGraph?nnn since this is the calling assembly (tried with TeklaGraphLib?nnn but then I get the “evaluation text” in the first view also.)
Yes I bought the GoDiagram about a year ago but I have’t had time to start the “move over” until just recently.
I’d be glad to send you a small application with the C# assemblies and the CWinFormsView design. It will take a day or so - to what e-mail adress can I send it?

godiagram at this domain.

Hi Jake,
Just curious if you guys have had any time looking at the demo app I sent?

We didn’t get it. I’ll send you an email, you can reply to that.

Hi,
I have solved the problem in my C++/C# mixed solution.
After some experimenting in the demo apps I realized what the problem was. In fact, in some cases, the C# demo apps have exactly the same problem.

Anyhow, thanks Jake (and others) for your time with this problem.

Can you send me some email on the nature of the problem? Sounds like it would be useful for me to hang on to what you’ve learned.