Yesterday I figured out why something didn't work as expected. The process was defined like this:
PROCESS cursor_tag(string entity, int id_code, byte entity);
The last argument is input for a switch statement, and the first one for printing some text. I added the last parameter without minding the rest. When I compiled I was suprised that the switch didn't work.... Until I found out that I used the same identifier twice.
Using two arguments with the same name but different type was ofcourse a very dumb thing to do, but the compiler did not complain at all. It compiled just fine, with me guessing why a case selection didn't work as I expected. :-[ I corrected it and now it works fine, as you can see in this bit of code.
PROCESS cursor_tag(string entity, int id_code, byte entity_type);
PRIVATE
int cursor_graph;
int text_graph;
string tag_text_string;
BEGIN
// create a window
cursor_graph=map_new(850,20,16);
// give the window a color
map_clear(0,cursor_graph,rgb(245,245,245));
// set the file and graph
file=0;
graph=cursor_graph;
// set it to scroll coordiates
ctype=c_screen;
// make the window semi-translucent
flags=0;
// set the position
x=600;
y=10;
// put it above all the other graphics
z=-400;
say("entity_type: "+entity_type);
// create custom tags depending on entity. some entities will use standard tag.
SWITCH (entity_type)
CASE DE_OBJECT:
tag_text_string = "selected entity: "+entity+" ["+id_code.count+"] ; x="+id_code.x+" ; y="+id_code.y+" ; z="+id_code.z+" ; angle="+id_code.angle+" ; flags="+id_code.flags+" ; Graph="+id_code.graph+" ; size="+id_code.size+" ; id_code="+id_code;
END
CASE DE_FIRST_PLANE:
tag_text_string = "selected entity: "+entity+" ["+id_code.father.count+"] ; x="+id_code.father.x+" ; y="+id_code.father.y+" ; z="+id_code.father.z+" ; angle="+id_code.father.angle+" ; flags="+id_code.father.flags+" ; Graph="+id_code.father.graph+" ; size="+id_code.father.size+" ; id_code="+id_code.father;
END
CASE DE_FLYING:
IF (id_code.gr == BEE)
tag_text_string = "selected entity: "+entity+" ["+id_code.count+"] ; x="+id_code.x+" ; y="+id_code.y+" ; incx="+id_code.incx+" ; incy="+id_code.incy+" ; dist x="+id_code.distx+" ; disty="+id_code.disty+" ; id_code="+id_code+" ; Bees="+num_entity_obj_kind.f_bee;
ELSE
tag_text_string = "selected entity: "+entity+" ["+id_code.count+"] ; x="+id_code.x+" ; y="+id_code.y+" ; incx="+id_code.incx+" ; incy="+id_code.incy+" ; dist x="+id_code.distx+" ; disty="+id_code.disty+" ; id_code="+id_code+" ; Ghosts="+num_entity_obj_kind.f_ghost;
END
END
DEFAULT:
tag_text_string = "selected entity: "+entity+" ["+id_code.count+"] ; x="+id_code.x+" ; y="+id_code.y+" ; id_code="+id_code;
END
END
text_graph=write_in_map(textfont, tag_text_string, ALIGN_CENTER_LEFT);
map_put(0, cursor_graph, text_graph, 75, 10);
TIMER[9]=0;
REPEAT
FRAME;
UNTIL (TIMER[9]>1)
ONEXIT:
// free memory
delete_text(all_text);
unload_map(0,cursor_graph);
unload_map(0,text_graph);
say("everything from cursor tag routine freed. "+father);
END
But this is something you can shoot yourself in the foot with if you're uncarefull. Is there a reason that this is not treated as an compile error (as in a feature) ? This made me wonder how a pascal v.s. a C compiler would have treated something like this. Maybe this kind of thing should produce at least a compiler warning, or an error.
I think a pascal compiler would say: Error! And a C compiler probably wouldn't mind it at all (as in a dangrous "feature"). ;D