Desktop productivity for business analysts and programmers

Addin for EG 4.1 in EG 4.2

Reply
N/A
Posts: 1

Addin for EG 4.1 in EG 4.2

Hello,

I have made some addin in VB.NET 2003 for EG 4.1 that worked just fine, but it´s not working in EG 4.2 any more. I have tried to recompile the addin in Visual Studio 2005 using EG 4.2 SAS.Shared.AddIns.dll, but with no success. The problem is that the property SasCode() doesn´t take variables from function Show() which are posted from the form.

Example:

In show() I have eg.:

Dim frm As MyAddinForm = New MyAddinForm

If frm.ShowDialog(Owner) = Windows.Forms.DialogResult.OK Then

var1 = frm.var ' variable var is declared by pressing OK button on the form

Return ShowResult.RunNow
Else : Return ShowResult.Canceled
End If

And in SasCode() I have eg.:

sb.Append(String.Format("{0};" & Environment.NewLine, var1))
SasCode=sb.tostring

Compiling the addin and running it in EG 4.2 the variable var1 is not worked with. When stating variable in SasCode(), thus eg

var1="something"
sb.Append(String.Format("{0};" & Environment.NewLine, var1))
SasCode=sb.tostring

addin works with it just fine. That´s why I think the problem is in transfering the variable from Show() to SasCode().

Please let me know where the problem can be, I´d be very grateful.

Sorry for my english and thank you very much for the advice Smiley Happy

Pavel
Community Manager
Posts: 2,712

Re: Addin for EG 4.1 in EG 4.2

Pavel,

The issue is that you cannot rely on the state of variables in the UI portion of your task to stay valid when your task is run. That's why you must store the state information using the XmlState property. EG will call the get method on XmlState when your task UI is closed. And then it will re-instantiate your task class and set the XmlState property when the task is run.

In this way, EG keeps the state of your task in the project for use later, even if you don't show the UI again (for example, when you run the process flow).

If it worked for you in 4.1, it was by luck...not by design. It just happened to be that the task objects were not disposed immediately. In 4.2, we improved the memory management of tasks to keep the application memory footprint lower, so this probably closed the loophole you relied upon in 4.1.

Chris
Ask a Question
Discussion stats
  • 1 reply
  • 97 views
  • 0 likes
  • 2 in conversation