LiveCode Forums.

I believe I have a major clue that explains the inconsistency of this. It is connected to BOTH the simulator and opening and closing LIVECODE. It is not affected by opening or closing a stack. I have sent a video to the bug team showing that simply opening and using the simulator and then going back to the file "breaks" the url(turl) capability in the original file. This explains why it's been so inconsistent - because I have been going back and forth between the simulator and the file to see what works and doesn't work - and the results are always changing.

It also explains why people trying the same thing haven't had problems - - because they haven't been using it with the simulator. To "cure" the problem, you have to close down the LiveCode program and reopen it.

I am hoping that the LiveCode team can identify this quickly and fix it.... so my sanity can be restored.

HOPEFULLY THE SOLUTION! Yesterday, I realized that moving between the simulator was causing the problem. It would work on the Mac, work on the simulator, but when I went back to the Mac is was broken. So I updated the bug info...and sure enough, the bug was confirmed. Here is the message:

What happened here is that somehow the tsNetLibUrl stack got unloaded from
memory after deploying to iOS simulator. So since calling [put URL)tUrl into
tResult] triggers some function calls from the tsNetLibUrl stack, and this
stack is now not loaded, the [put URL)tUrl into tResult] call fails silently.

Workaround:
After deploying to iOS simulator and returning to the IDE, type in the msg box:

start using stack "tsNetLibURL"

This will restore the IDE functionality when calling [put URL)tUrl into
tResult] in the sample stack.

I guess this was introduced at some point after LC 8.1 DP-3, and should affect
the Community version. My comment: It actually affects the Indy as well - that is what I have been using.

Here's hoping for some consistency in url(turl) calls!

Hi all,

After reading Carolyn's reply here, I realised that my original comment in the bug report was not what I meant to write. I have now corrected it. This bug is *not* expected to affect the Community edition, since the Community edition does not use tsNet.

Best regards,
Panos
--