Updating to 8.0.81.1667, solved a few errors, but one remains.
Error 10 (E0) Internal error: Object reference not set to an instance of an object. 0 0
No line number. Large project, no idea how to figure out what is wrong. Doesn’t seem to be related to previous posts. What to do next?
Tricky. The easiest thing is to mail the project to me (ck at remobjects.com) , i’ll keep it safe and throw it away once I’ve fixed the issue. If that’s not an option it comes down to checking which phase it fails in, maybe look at the compiler callstack (Which is obfuscated but sometimes gives a clue)
I don’t mind mailing it to you but it’s pretty large. Let me look at the compiler callstack. That shows up in the Output tab?
Also, does that error abort the compile? Can I zero in on it by dropping syntax errors into the code?
Ok, found the code that was causing the error. It’s coming from remobjects.oxygene.dynamic.dll
curl:="/"+messages.&id+"/comments?fields=message,from,parent,attachment,created_time&filter=stream&summary=0";
fbComments:=fbClient.Get(curl) as Facebook.JsonObject;
for each comments:dynamic in fbComments[‘data’] as System.Collections.IEnumerable do
begin
lastPostConversationDate:=facebookGMTDateToDateTime(comments.created_time as string); //the latest comment will be last
if (comments.parent as string) = nil then // this is the line that causes the error. Note the line above that does NOT cause an error.
I tried (but made no difference) :
updating the dll to remobjects.elements.dynamic
setting the Target Framework to 4.5 and 4.5.1. and removing the dll from the references ( does 4.5 handle dynamic types? Apparently not because it still says it requires the dll ) .
A strategy for dealing with this problem would be greatly appreciated.
Update: Old version used to have to cast dynamic member as string before checked for null, new version requires the opposite, so … if (comments.parent) = nil … solves the problem. I assume that it works but I have not tested it yet because: New problem. Old version used to handle dynamic records, new version does not.
for each comments:dynamic in fbComments['data'] as System.Collections.IEnumerable do
begin
if (comments.parent) = nil then // is top level comment
begin
fromName:=comments.from.name as String; //this throws a type mismatch compiler error, old version did not
for each fromNameO:dynamic in comments.from do
fromName:=fromNameO.name as String; //this compiles, but I have no idea if it works, plus it is very inelegant.
Does anyone have a method for accessing records inside of dynamic objects that should be (and was) accessible with dynamicobject.record.string without creating a useless for loop (Which may or may not actually work)?
I’ve managed to reproduce the NRE in the compiler for the IF (logged as 70748: NRE in compiler with Dynamic code & fixed for the next build). However I cannot reproduce fromName failing, with our without the cast. How is fromname defined?
NRE is the error that stops the compiler? It would really be nice if the compiler reported the last successful line of code compiled with those, it would have saved me some hours.
Fromname is a string. If the source is the first branch of the dynamic record, fromname := dynrec.somestring, it works. If it is from the second or higher branches, it does not such as fromname := dynrec.dynsubrec.somestring. My workaround was copy the subrecords into their own record dynSubrecCopy:=dynrec.dynsubrec; fromname:=dynSubreccopy.somestring;
Even then, comparison operators don’t work right. " If dynsubrec <> nil " always returns true even if, in the debugger, dynsubrec is showing as nil. I had to turn that into an attempt at casting an internal string and catch it in a try except statement. None of this is very elegant, but the dll really is not very stable.
NRE yes. I’ve added some code that does this for this case and cases like it, but it’s not as easy as it sounds to always get the position of the last node.
I think I fixed that nested issue a while ago already, does that show on the beta for you?
Just having the user control it was in would have been a time saver, I had to drop syntax errors all over my project to see which one started to compile but didn’t finish. My fist Turbo Pascal came on a 8 1/2" floppy disk and it used to just show the line number it was compiling, which I understand is too much. But it would be nice to have a verbose mode to narrow things down a little in situations like that, even if it takes 10 minutes to compile a big project.
I am trying to stay away from betas at the moment, I have to get my own code stable on Net 4.5. Is there a beta for the dll?
Obviously it shouldn’t happen at all, the NRE. the error isn’t in the dynamic dll, it’s in the compiler. Note that Oxygene isn’t a single pass compiler like old Pascal compilers are, thats what makes it trickier. But it should show it the next time you have an error alike this.
I do suggest you use the (upcoming) beta for the dynamic fixes.
Yeah, I understand; I know more now about how it makes multiple passes than I really wanted to. All right I’ll watch for the beta.