I'll try to reproduce this-- but did you catch the EInternetException? You must.
Trying online activation without network -> errorSolved
Hi wyatt,this night i was testing the online activation EInternetException error (in delphi).
So I removed the network cable and began the activation process. The software crashed without any error message.
My debugger was pointed inside ntdll32.dll if i didn't get wrong and it happened after the first update progress call.
If i connect the cable the activation will go on completely and successfully
This happened with product keys.
The same procedure with a trial extensions wont generate this error.
I'll try to reproduce this-- but did you catch the EInternetException? You must.
Sure I catched it, but also if i would not catch it a Delphi program would never crash without a message. The strange effect is the debugger is stopping like an error happened in the middle of asm32 code, but without a message box. Then if you are pressing run the program will crash directly.
I can't reproduce this error. I tried reproducing it using Delphi 7 and using our example Delphi project.
Do you get this with other languages you're using? (other than Delphi)
Are you using the x86 binaries of TurboActivate? (Delphi does not run as a 64-bit process).
Is the TurboActivate "TurboActivateUnit.pas" files from the same version of TurboActivate you're using? Because some function definitions changed from TurboActivate 2.x to 3.x. So you must include the correct TurboActivateUnit.pas file with the version of TurboActivate you're using.
I rewrote the turboactivateunit.pas but I am updating it everytime i'm finding changes in your one trough our merge system.
I'm actually using the 32bit executables sure and not using delphi xe 2 64bit compiler yet.
And I'm using Delphi 2010 inside a Windows 7 32bit vmware player virtual machine.
I did a better test with the project compiled as Release.
The activation is working flawlessly while my network cable is plugged in (the physical one). When I disconnect it the trial extension online activation is working and giving correctly the EInternetException error, the online activation is making the first call to the progress delegate that i setted using SetProgressDelegate and after it the debugger is popping out pointing in the middle of kernel32.dll.
:75cbdca6 ; C:\Windows\system32\kernel32.dll:1005883c :10077849 :7737718b ntdll.RtlRaiseStatus + 0x86:77377017 ntdll.KiUserExceptionDispatcher + 0xf:10053737 :10003b37
After this it will crash without any information, like a stack overflow or whatever.
I declared
TProgressCallback = procedure(Progress: Int32); stdcall;
Maybe this is wrong? But if my network cable is plugged in it is working so i don't suppose it is wrong.
I debugged the asm code. In the same method (or procedure) where you call the progress delegate, counting the call to it as 0, the 11th is giving this error. Without debug symbols i can't be more precise.
First of all, you shouldn't be using "SetProgressDelegate" -- we haven't documented it and it doesn't give a "good" progress. It's more of a "quick and dirty" progress meter. We plan to make a better public function later.
But if you do intend to continue using it then you need to make sure you're using the right calling convention. The calling convention for both "SetProcessDelegate" and the callback function is "cdecl" not "stdcall" like you have.
If I were to guess this is the root of the problem.
You are the best!
The strange part is that this was happening JUST in case I was offline and the error should be rised. In all the other cases was always going on correctly.
You are the best!
It's my pleasure.
The strange part is that this was happening JUST in case I was offline and the error should be rised. In all the other cases was always going on correctly.
Mixing up calling conventions can cause a whole lot of odd behavior (see this for the differences between cdecl and stdcall). I'd have to dig into the assembly to see exactly what was happening, but if I were to guess I would say you were still getting an error when you were connected to the internet, however it was only a fatal error when you were offline.
Eh yes, i was knowing the differences but because the method was undocumented in Delphi I preferred to start by tests to find the right calling convention. So I started with stdcall and I would move to the others if it would give an error. Unluckily it didn't give an error during my tests, but just after few days and this strange test... I really didn't guess it would be exactly the same of all the other functions declared there... my error. 😛
At the end thanks! I would not notice it because of the situation 😛