This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Everything was working fine using 2.2. Just installed 3.1 and get an 'object reference not set exception' stacktrace as shown below. Any ideas ? at Mindscape.LightSpeed.Entity.TrackChange(String , Object , Object ) |
|
|
|
|
Have you found any solution we are facing same issue |
|
|
|
|
Can you provide a repro? |
|
|
|
|
I can pass you a simplified version of the VS solution in which there is a problem. How should I send it to you ? |
|
|
|
|
You can attach a zip file using the Options tab. If the repro contains sensitive information then you can email it to us but Gmail can be a bit finicky about letting certain file types through so be sure to strip out any binaries (and/or change the zip file extension). |
|
|
|
|
Tried to use add attachment using Options but received unhandled exception mesage (!!!) What e-mail address should I e-mail this to (total size is about 4.5MB) |
|
|
|
|
Hi Stephen,
You can send the email to ivan at mindscape.co.nz
Ivan: feel free to delete the post once you have the email message. |
|
|
|
|
Tried e-mailing ivan@mindscape.co.nz but received delivery failure reply. Is the above correct ? Note I'm attaching a file which is about 4.5MB. Could that cause a problem ?
|
|
|
|
|
Hi Stephen, It is more likely that there are binary files in the attached file (even if it's a zip). We use Google for Domains for our email hosting and they have a blanket rule to block attachments with executable files attached. You could try:
I hope that helps, John-Daniel Trask |
|
|
|
|
I've tried zipping up the solution after removing dlls etc. |
|
|
|
|
Further info ConsoleApplicaiton1 is the start up solution. If you run this you will get an exception in the line |
|
|
|
|
The problem is that ProjectionTask is not calling the Initialize method before setting properties. This means that a lot of initialisation gets bypassed, so the entity internals are not fully set up when you start working with it. So when the ProjectionTask constructor starts setting persistent properties, the Entity.Set method fails. From looking elsewhere in the code (and from adding the call in myself), the reason you don't call Initialize is that you get an exception when you do so. This is due to a broader issue with the entity constructors in general, and you need to address this issue rather than trying to bypass it by avoiding the Initialize call. The trouble is that entity construction in Visual Basic requires a little bit of extra code: I'll explain why later, but first I'll go into the solution. In VB, the entity constructor needs call the base class constructor with an autoInitialize option of False, and then call Initialize. Consequently, every VB entity needs to define two constructors, a public parameterless constructor and a protected constructor with a boolean autoInitialize argument. (Actually, you don't need the latter in classes that are never used as base classes, but it's safest just to get into the habit.) So every VB entity should contain the following constructor code: Snippet Public Sub New()
Why do you need to do this little dance in VB when you don't need to in C#? It is to do with when field initialisers run. Consider an association field like this: Snippet Private ReadOnly _tasks As New EntityCollection(Of Task)() LightSpeed requires this initialisation to have completed when Entity.Initialize runs. In Visual Basic, this doesn't happen until after MyBase.New() has returned. Now if you accept the default constructors, these eventually end up calling the default Entity constructor, which automatically calls Initialize(). And this happens before the field initialisers have run, which causes Initialize to blow up. So you need to make sure that your constructor chain doesn't end up calling the default Entity constructor. Instead it needs to end up calling the Entity(bool autoInitialize) constructor with an argument of False. This overload doesn't call Initialize, so it doesn't blow up on the uninitialised fields. But Initialize still needs to be called at some point. So you need to do this in your default constructor, after the chain of constructors has run, i.e. after MyBase.New has returned. And it's safe to do so at this point because VB has now run the field initialisers. Hope this makes sense! If it doesn't, you probably don't need to worry about it too much -- the key thing is that every VB entity must define those two constructors as shown above. Once I'd made this change throughout your inheritance hierarchy, your sample application ran successfully for me with the latest LightSpeed 3.1 build. Let me know if you need any more info! |
|
|
|
|
I've got this working now. Many thanks for your help. |
|
|
|
