ID:138313
 
That the TEXTAREA interface-type boxes in forms have you input text in a different font than you do in the TEXT interface-type boxes? Is there a way to change this? (I want to use the TEXTAREA interface but the font provided--the same one for this post type-in box--is too big for me.)

Also, when I create the form and assign default values and such to the little boxes, and then I look at them, I see that a space has been added in front of the values for TEXTAREA boxes.

Arg... the Dream Seeker has gotten again so that Login() doesn't seem to be processing completely... this only happened once before and I didn't report the bug. I will have to restart my computer and come back and edit this later if further testing reveals anything.

Here we go... okay, the third thing is that in the value assignation of ProcessForm, the desc variable (the description of the room) apparently gets turned into something that no longer gets displayed when people look at the room they're in.

Now, I can't figure out from testing what might be causing this. A listing of the room's variables reveals that the desc variable is indeed what I changed it to. And imbedded, the new room description can be displayed fine, but my Look() proc imbeds it then sends that text string to another proc which displays it whole (not imbedded in anything else) to the player who's looking. Except after I change the room's description with this form, that no longer works. But that can't be the whole problem... and it might not be any of it... because I can change other variables (such as the listing of the room's exits) and they display just fine when I look at the room.

I have this problem no matter how short I make the new description. I know this might be a bug in my own code but I have no idea where else to look. Variable gets changed, it just no longer displays when put through the same procs that used to display it fine... even if I "changed" it to the exact same text it was before.

Z
On 11/5/00 12:42 pm Zilal wrote:
That the TEXTAREA interface-type boxes in forms have you input text in a different font than you do in the TEXT interface-type boxes? Is there a way to change this? (I want to use the TEXTAREA interface but the font provided--the same one for this post type-in box--is too big for me.)

Courier? You don't like Courier? Courier is cool! =)

Anyways, that's Microsoft's problem, not Dantom's... you can always go look at W3C's HTML 4.0 specs to see if you can change the font face in a form field... wouldn't be much help with this library, though (unless you can pass custom INPUT tag arguments somewhere).



Arg... the Dream Seeker has gotten again so that Login() doesn't seem to be processing completely... this only happened once before and I didn't report the bug. I will have to restart my computer and come back and edit this later if further testing reveals anything.

I've had problems with Login() in the past, and so it seems that AIKaiser (a person I'm guiding) is having problems with it too.
In response to Spuzzum
On 11/5/00 1:22 pm Spuzzum wrote:
I've had problems with Login() in the past, and so it seems that AIKaiser (a person I'm guiding) is having problems with it too.


What kind of problems?
On 11/5/00 12:42 pm Zilal wrote:
That the TEXTAREA interface-type boxes in forms have you input text in a different font than you do in the TEXT interface-type boxes? Is there a way to change this? (I want to use the TEXTAREA interface but the font provided--the same one for this post type-in box--is too big for me.)

Looking at the w3.org site (which is where the definition of HTML resides) it looks like style sheets can be used for this.

Info at:

Text area info

How to use styles


Also, when I create the form and assign default values and such to the little boxes, and then I look at them, I see that a space has been added in front of the values for TEXTAREA boxes.

It appears to be line #273 in form.dm:

html += "


"


Change this to:

html += "


"


In response to Deadron
On 11/5/00 1:23 pm Deadron wrote:
On 11/5/00 1:22 pm Spuzzum wrote:
I've had problems with Login() in the past, and so it seems that AIKaiser (a person I'm guiding) is having problems with it too.


What kind of problems?

I don't quite remember, but I think I had a locate() proc and a sound() proc together, and neither were called. When I put in a debug check after the ..(), it didn't say "Logged in!" whenever I logged in, either.


After review of AIKaiser's ICQ messages, I think that actually it was pilot error in his case. Cancel that. =)
In response to Deadron
On 11/5/00 1:23 pm Deadron wrote:
What kind of problems?

Well, it's pretty much like I said... it seems like I'm "not fully logged in." Only the verbs panel will appear instead of all the panels that are supposed to be there, and if there's a map it may be incompletely loaded, with black squares in the place of some icons. And procs that are supposed to be called toward the end of Login() don't get called. This will happen in every world I try to connect to until I reboot the computer.

Z
Here we go... okay, the third thing is that in the value assignation of ProcessForm, the desc variable (the description of the room) apparently gets turned into something that no longer gets displayed when people look at the room they're in.

Okay... it occurred to me that this was due to the fact that my code says essentially "if (nightdesc == "") Display(desc)". I am not changing nightdesc when I submit these forms, but it must be changing it for me anyway, from "" to null, presumably. There are some places in my code where it matters. Is it possible to alter the forms library to keep it from doing that? I cannot think of an appropriate hack for my own code, as sometimes I want to make things null and sometimes "" and sometimes 0.

Now, I say "presumably" up there because today, despite the fact that I have changed no code I feel is relevant, the submit button on the form in question no longer works (does not call ProcessForm()), so I can't test the above hypothesis. And I just cannot figure out why this button no longer works. Any ideas?

Furthermore, while trying to figure out why this was, I commented out some code--properly, I thought, I had a nice grey block of code with normal black code on top and bottom--and compiled, and the compiler was convinced that the code ended in a commented out section or something. That my */ was being ignored, I assume. It had been at the end of this line:

if (src.form_title:atmosphere.len > 0) page += "<A href=\"byond://# roomedit scriptrem [src.form_title:tag] \">Remove script</A><BR>"

I put it on a new line after that, and the compiler was happy.

Lastly... and back to forms... when the form values get initialized, and I look at the page in the browser window... text strings seem to be getting cut off after apostrophes. Or rather, before apostrophes, since the apostrophes aren't there either. "Cerule, Crazy Abdul's" turns into "Cerule, Crazy Abdul".

Z
In response to Zilal
On 11/7/00 11:19 am Zilal wrote:
Here we go... okay, the third thing is that in the value assignation of ProcessForm, the desc variable (the description of the room) apparently gets turned into something that no longer gets displayed when people look at the room they're in.

Okay... it occurred to me that this was due to the fact that my code says essentially "if (nightdesc == "") Display(desc)". I am not changing nightdesc when I submit these forms, but it must be changing it for me anyway, from "" to null, presumably. There are some places in my code where it matters. Is it possible to alter the forms library to keep it from doing that? I cannot think of an appropriate hack for my own code, as sometimes I want to make things null and sometimes "" and sometimes 0.

If I get some time today, I'll take a look. My best advice for the longterm, however, would be to treat null, 0, and "" identically. A lot of libraries will expect that, since the common comparison: if(!X) will be true for any of the three "null" variations.

Now, I say "presumably" up there because today, despite the fact that I have changed no code I feel is relevant, the submit button on the form in question no longer works (does not call ProcessForm()), so I can't test the above hypothesis. And I just cannot figure out why this button no longer works. Any ideas?

Usually that means that client.Topic() is being blocked somehow. If you don't have any Topic() procs, you might want to test if it is being reached at all, by doing:

client/Topic(T)
world << "[T] reached!"
return ..() // very important!

And of course put debugging before and after the form is executed so you can see where things are getting blocked.

Furthermore, while trying to figure out why this was, I commented out some code--properly, I thought, I had a nice grey block of code with normal black code on top and bottom--and compiled, and the compiler was convinced that the code ended in a commented out section or something. That my */ was being ignored, I assume. It had been at the end of this line:

if (src.form_title:atmosphere.len > 0) page += "<A href=\"byond://# roomedit scriptrem [src.form_title:tag] \">Remove script</A><BR>"

I put it on a new line after that, and the compiler was happy.

I've seen something like this before. I'll try to test your case. That is strange.

Lastly... and back to forms... when the form values get initialized, and I look at the page in the browser window... text strings seem to be getting cut off after apostrophes. Or rather, before apostrophes, since the apostrophes aren't there either. "Cerule, Crazy Abdul's" turns into "Cerule, Crazy Abdul".

Ooh. I bet the ' is ending the text. That sounds like a bug. You can try to escape it \' to see if it fixes it. Dan will have to take a look.
In response to Tom H.
First... if you hit reply to Deadron's message below, see if some of his message ends up outside the text box, on the black part of the page it, for you as it does for me.

On 11/7/00 2:03 pm Tom H. wrote:
If I get some time today, I'll take a look. My best advice for the longterm, however, would be to treat null, 0, and "" identically. A lot of libraries will expect that, since the common comparison: if(!X) will be true for any of the three "null" variations.

I have another problem... when a form's variable is initialized to 0, it displays as nothing at all, as if it's null. If it is 0 and just not displaying as such, well. But if it has been changed to null as ""'s have, is the code smart enough to know that it *used* to be 0, and accept that my input in the little box is thus to be taken as a number rather than text string, as it does in such cases when the initial value is a number?

From the doc: "If the input type of the variable is numeric (achieved by initializing the variable to a number), the input from the text box will be automatically converted to a number for you."

Oh, in a similar vein... imbedded variables of "" or null in browsed pages seem to be displayed as 0 at particular times. The only thing the instances I see seems to have in common is that they're at the beginning of a line on the page (and likely in the code too; their line would have been something like 'page += "[src.field1][src.name]"'.

Usually that means that client.Topic() is being blocked somehow.

I haven't changed anything in the code, but now it works. I know I'm not crazy (about this, anyway)... I wonder if my Dream Seeker had just been acting up again. Though I had closed it and opened another one after I saw the problem. Ah, the mysteries of coding...

Ooh. I bet the ' is ending the text. That sounds like a bug. You can try to escape it \' to see if it fixes it. Dan will have to take a look.

Escaping it does not work.

These forms things are not of utmost priority right now, as I still have the clunkier system with links and prompts in place and except for the prompts-and-macros problem, it still works fine.

What I am actually curious about is where on the List the ability to code games to open with the info panels suppressed (unchecked in the Layout menu, and undepressed in the buttons above the text window) is. Or, barring that, whether the DS will ever remember how it's been laid out for each game.

Oh, too, I wonder if we might ever have different "sets" of macros... so that I could create a Cerulea set and a Sneak set and who knows. Made by the player, not the designer, of games, as the designer cannot anticipate all the little things I might want to macro.

And I wonder if we might be able to override with our own macros keys that dantom currently uses, such as F1. All the ones like that.

Not too much for one post, is it?

Z
In response to Zilal
On 11/7/00 5:22 pm Zilal wrote:
First... if you hit reply to Deadron's message below, see if some of his message ends up outside the text box, on the black part of the page it, for you as it does for me.

Yep, I get that. As for the rest of your post, I'll read that now. =)


What I am actually curious about is where on the List the ability to code games to open with the info panels suppressed (unchecked in the Layout menu, and undepressed in the buttons above the text window) is. Or, barring that, whether the DS will ever remember how it's been laid out for each game.

Oh. I see what you mean now... you want the stat panels to work if you want, but you don't want the panels to be available unless someone chooses to enable the panels in Dream Seeker, right? Um... well, that would be better to have it as client-side, not designer-controlled... it could lead to serious confusion!

And I wonder if we might be able to override with our own macros keys that dantom currently uses, such as F1. All the ones like that.

I hope so.
In response to Spuzzum
On 11/7/00 9:09 pm Spuzzum wrote:
Oh. I see what you mean now... you want the stat panels to work if you want, but you don't want the panels to be available unless someone chooses to enable the panels in Dream Seeker, right? Um... well, that would be better to have it as client-side, not designer-controlled... it could lead to serious confusion!

Well, basically. It's like how the map and panels don't show up anymore when you connect to a game that doesn't use them... but you can still make them show up if you want to.

Z
In response to Zilal
Well, basically. It's like how the map and panels don't show up anymore when you connect to a game that doesn't use them... but you can still make them show up if you want to.

Yep, that's what I meant too.