Browse() trouble

ID:264374
 
Mar 30 2009, 2:40 pm (Edited on Mar 30 2009, 2:59 pm)
Code:
Click()
...
var/html = "<html><frameset rows=\"15%,85%\"><frame src=Nav /><frame src=Main name=\"display\" /></frameset></html>"
var/Nav = "<body>...</body>"
var/Main = "<body>...</body>"
var/Stats = "<body>...</body>"
var/Skills = "<body>...</body>"
var/Image = file("fileHere")
usr << browse(Nav,"file=Nav;display=0")
usr << browse(Main,"file=Main;display=0")
usr << browse(Stats,"file=Stats;display=0")
usr << browse(Skills,"file=Skills;display=0")
usr << browse_rsc(Image,"Image")
usr << browse(html,"window=[name]")


Problem description:

Well, this is sort of a round two on this. (Though round one was months ago)

So, I'm trying to show some complicated HTML in a browser window, which involves frames, and thus, requires several separate HTML documents.
Plan A was to create several files on the host computer, then use browse_rsc() to transfer the files, and then use a browse() to show the main file. It worked, but I couldn't delete the original files, for some reason that I still haven't quite worked out. (Fdel wasn't working, and I tried several things, the file object, the file path, etc.)

Someone suggested that making the original files wasn't necessary, that I could simply transfer the text with browse_rsc(), so I've been trying that. (I figured out that you have to actually use browse) It looks like it should be working but it's not.

Now, bear in mind, that this code was working correctly (with the exception of the fdel part) before, when the four variables (Nav,Stats,Skills, and Main) were file objects contain the exact same HTML, and instead of the four browses, I had browse_rsc(Nav,"Nav").

When I run this right now, I don't get any error messages, but nothing happens.


EDIT: Problem solved, though I still am confused. Moving the browse_rsc for the Image to the spot above the first browse, fixed it. (I moved it back and forth to check) Does the order matter? I don't see why it would. Should this be a bug report?
Mar 30 2009, 6:30 pm
As far as I know, order does matter. The browse_rsc has to be called to put the image in the cache before it loads the html, putting it after all the browse() procs would mean that it would load the image after it already tried to display it (assuming you're trying to display this image in one of those browse() procs anyway).

So yeah, loading it first through browse_rsc, then displaying it would be the logical answer.
Mar 31 2009, 10:53 am
In response to Commander_ACE
Order always matters, whether it's Order of Operations or not. All languages, not just DM, work that way. And your "Language Arts" classes back in Elementary School should teach you that you read Top to Bottum; Left to Right (in the United States at least).

The compiler will execute things one line at a time, so if you call a proc before setting a variable, that proc will be sought to its end before that variable gets set. The only way to prevent the compiler from reading things one at a time is the spawn() proc, in which case the compiler will call the proc AND set the variable at (virtually) the same time.
Mar 31 2009, 11:05 am
In response to Spunky_Girl
Spunky_Girl wrote:
The only way to prevent the compiler from reading things one at a time is the spawn() proc, in which case the compiler will call the proc AND set the variable at (virtually) the same time.

Wrong; while in some other languages you can program multiple execution threads running concurrently doing their stuff at the same time, DM is strictly single-threaded and it's not possible to change that. Only one procedure or thread can execute at a time, DM simply handles the execution so it jumps between functions accordingly. This amounts to a good part of the language as it keeps simplicity and prevents a whole slew of possible headaches from things running concurrently.
DM is doing a similar thing when you use spawn(), which queues a psuedo-thread of sorts (or a mini-function perhaps) to run some time later, but it still only executes on its own when nothing else is currently executing. Even if you use spawn(-1) for the minimum possible delay, your spawned code will not execute until either the current proc finishes (returns) or a sleeping function is called (sleep() or other functions that pause the procedure like input() and Export()).
This means if you want things to happen as close to each other as possible and run straightly consecutively, spawn() isn't always a good idea to use. For example, you're better off doing something like this- 
for(var/mob/M)
    do_stuff_with_this_mob

...than this- 
for(var/mob/M)
   spawn()
      do_stuff_with_this_mob
Mar 31 2009, 12:20 pm (Edited on Mar 31 2009, 1:02 pm)
In response to Kaioken
How do you know so much about the DM engine, Kaioken? o.O Have you worked with Lummox/Dan/Tom at any point in the life of BYOND?
Mar 31 2009, 12:28 pm
In response to Spunky_Girl
He's partly right, though.
Mar 31 2009, 12:38 pm (Edited on Mar 31 2009, 12:43 pm)
In response to Spunky_Girl
Mmhm, you don't need to be related to the staff at all to know this stuff (pun intended). I'm nowhere need "guru level", either. It's common knowledge that DM is single-threaded, and then you can go along from there with common sense and experimenting/experience.

EDIT: Limmox! That sounds fanny. :P
Mar 31 2009, 3:47 pm
In response to Spunky_Girl
Spunky_Girl wrote:
How do you know so much about the DM engine, Kaioken? o.O Have you worked with Lummox/Dan/Tom at any point in the life of BYOND?

If you've ever taken a computer architecture class (or read up on the subject religiously), simply hearing that DM is single-threaded allows you to infer roughly how the system works.
Apr 4 2009, 4:27 pm
In response to Ephemerality
No, I've never taken any classes other than IC3 (which is just basic computer hardware/software knowledge...VERY basic), or read any online articles (other than that for modular programming), but I can gain a basic inference of what "single-threaded" means just by reading it.