Hi,
A newcomer to .Net (I've held out as long as I can.).
I am using VS.Net 2003.
I am writing some web apps and I am confronted with the usual issues that
one faces when coming from a Windows, Apache, Mysql, PHP (WAMP) background.
Is it a common practice, or even acceptable, to insert addition form tags to
avoid the issues of passing form data to another webform, triggering
validator controls for unrelated input controls, etc. ?
Any comments, welcome.
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =---- 12  1494 
"Spam Catcher" <sp**********@r ogers.com> wrote in message
news:Xn******** *************** **********@127. 0.0.1... "Mike Gaab" <mi****@montana .com> wrote in
news:11******** *****@spool6-east.superfeed. net:
Is it a common practice, or even acceptable, to insert addition form
tags to avoid the issues of passing form data to another webform,
triggering validator controls for unrelated input controls, etc. ?
I don't really understand what you're saying here. An ASP.NET application
usually has only 1 FORM tag per page. I have never needed more than 1 form
tag.
Does this mean your webpages have only one submit button per page?
You decide what to do with the data on the page during PostBack : )
Coming from the WAMP world, that is trivial.
Additional comment:
I am just not used to being limited to one form per page and how
ASP.Net passes form data to another webform page. For example,
since ASP.Net is emulating the desktop event model, one has to use things
like Server.Transfer to get form data to another page. This just seems a
little clunky. On the other hand, ASP.Net does some really clever stuff that
I enjoy very much.
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Hi Mike,
The ASP.Net object model is designed to work something like a Windows Form,
and emulate state as well as events by various mechanisms, such as PostBack
(the WebForm submitting to itself), ViewState, and so on. As HTTP is
stateless, there is a rather substantial infrastructure to support this
emulation.
It is really quite elegant, all things considered. So, if you can get your
head around the object model, you can see that Server.Transfer and
Response.Redire ct are more in line with that object model. The browser
represents the interface, and the server is the business logic that drives
it. Now, that said, it is certainly possible to add an additional,
non-server form to a page, and have that form post to another ASP.Net page
in the same application. However, this more or less breaks the object model,
as anything outside the WebForm is not a Server Control, and does not follow
the object model. Having another form on a page is sometimes useful for
posting to another Application or Domain, but other than that, I think that
once you get used to the ASP.Net object model, it will "click" and you will
feel quite comfortable with it.
There is something to be said for convention. It provides common ground, and
eliminates the necessity to remember a variety of different methodologies,
as well as making development in a team, or taking on work from another
developer much easier (less of a learning curve). I would suggest you stick
with it, and see if you don't grow to like it a lot.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"Mike Gaab" <mi****@montana .com> wrote in message
news:11******** *****@spool6-east.superfeed. net... Hi,
A newcomer to .Net (I've held out as long as I can.).
I am using VS.Net 2003.
I am writing some web apps and I am confronted with the usual issues that
one faces when coming from a Windows, Apache, Mysql, PHP (WAMP)
background.
Is it a common practice, or even acceptable, to insert addition form tags
to avoid the issues of passing form data to another webform, triggering
validator controls for unrelated input controls, etc. ?
Any comments, welcome.
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption
=----
"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:Om******** ******@TK2MSFTN GP12.phx.gbl... Hi Mike,
The ASP.Net object model is designed to work something like a Windows
Form, and emulate state as well as events by various mechanisms, such as
PostBack (the WebForm submitting to itself), ViewState, and so on. As HTTP
is stateless, there is a rather substantial infrastructure to support this
emulation.
It is really quite elegant, all things considered. So, if you can get your
head around the object model, you can see that Server.Transfer and
Response.Redire ct are more in line with that object model. The browser
represents the interface, and the server is the business logic that drives
it. Now, that said, it is certainly possible to add an additional,
non-server form to a page, and have that form post to another ASP.Net page
in the same application. However, this more or less breaks the object
model, as anything outside the WebForm is not a Server Control, and does
not follow the object model. Having another form on a page is sometimes
useful for posting to another Application or Domain, but other than that,
I think that once you get used to the ASP.Net object model, it will
"click" and you will feel quite comfortable with it.
There is something to be said for convention. It provides common ground,
and eliminates the necessity to remember a variety of different
methodologies, as well as making development in a team, or taking on work
from another developer much easier (less of a learning curve). I would
suggest you stick with it, and see if you don't grow to like it a lot.
Hi Kevin,
Yeah, I agree.
A few questions...
When I use Server.Transfer ( "some.aspx" ) or
Server.Transfer ("some.aspx" , true), there doesn't seem to be any difference
in functionality. The docs say that the boolean preserves form and query
string data from the calling webform but I can still get at the form data by
either using the Request object or by getting a reference of the calling
webform via the Context.Handler property
and calling the appropriate get method(s).
The docs also say that Server.Transfer stops execution of the previous
webform. If that is the case, then how can I can a reference to it? I guess
I am thinking that stopping execution is
equivalent to destroy.
One last thing, the URL in the browser still points to the calling
webform page.
Please explain. Thanks.
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Sure Mike, When I use Server.Transfer ( "some.aspx" ) or
Server.Transfer ("some.aspx" , true), there doesn't seem to be any
difference in functionality. The docs say
Yes, the docs are a bit confusing. Setting the second parameter to false is
what clears the Collections.
The docs also say that Server.Transfer stops execution of the previous webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.
Exactly. It stops the previous Page class from continuing its execution. The
class is not destroyed. The difference is that the previous page is no
longer processing the Request. You have "transferre d" execution to the new
Page class.
One last thing, the URL in the browser still points to the calling
webform page.
That is true, and correct. Server.Transfer is a server-side transfer of
execution. The execution of the HTTP Request is handed off to another Page
class. The Request is not changed. The difference between Server.Transfer
and Response.Redire ct, is that Response.Redire ct actually sends a Response
back to the client browser, telling it to request another URL. Therefore,
the URL of the Request changes, as it is actually a second Request from the
client. Server.Transfer only changes the server-side handler of the current
HTTP Request.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"Mike Gaab" <mi****@montana .com> wrote in message
news:11******** *****@spool6-east.superfeed. net...
"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:Om******** ******@TK2MSFTN GP12.phx.gbl... Hi Mike,
The ASP.Net object model is designed to work something like a Windows
Form, and emulate state as well as events by various mechanisms, such as
PostBack (the WebForm submitting to itself), ViewState, and so on. As
HTTP is stateless, there is a rather substantial infrastructure to
support this emulation.
It is really quite elegant, all things considered. So, if you can get
your head around the object model, you can see that Server.Transfer and
Response.Redire ct are more in line with that object model. The browser
represents the interface, and the server is the business logic that
drives it. Now, that said, it is certainly possible to add an additional,
non-server form to a page, and have that form post to another ASP.Net
page in the same application. However, this more or less breaks the
object model, as anything outside the WebForm is not a Server Control,
and does not follow the object model. Having another form on a page is
sometimes useful for posting to another Application or Domain, but other
than that, I think that once you get used to the ASP.Net object model, it
will "click" and you will feel quite comfortable with it.
There is something to be said for convention. It provides common ground,
and eliminates the necessity to remember a variety of different
methodologies, as well as making development in a team, or taking on work
from another developer much easier (less of a learning curve). I would
suggest you stick with it, and see if you don't grow to like it a lot.
Hi Kevin,
Yeah, I agree.
A few questions...
When I use Server.Transfer ( "some.aspx" ) or
Server.Transfer ("some.aspx" , true), there doesn't seem to be any
difference in functionality. The docs say that the boolean preserves form
and query string data from the calling webform but I can still get at the
form data by either using the Request object or by getting a reference of
the calling webform via the Context.Handler property
and calling the appropriate get method(s).
The docs also say that Server.Transfer stops execution of the previous
webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.
One last thing, the URL in the browser still points to the calling
webform page.
Please explain. Thanks.
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption
=----
"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Sure Mike,
When I use Server.Transfer ( "some.aspx" ) or
Server.Transfer ("some.aspx" , true), there doesn't seem to be any
difference in functionality. The docs say
Yes, the docs are a bit confusing. Setting the second parameter to false
is what clears the Collections.
So the default setting is true, is that is why setting it true seems to have
no effect?
The docs also say that Server.Transfer stops execution of the previous webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.
Exactly. It stops the previous Page class from continuing its execution.
The class is not destroyed. The difference is that the previous page is no
longer processing the Request. You have "transferre d" execution to the new
Page class.
One last thing, the URL in the browser still points to the calling
webform page.
That is true, and correct. Server.Transfer is a server-side transfer of
execution. The execution of the HTTP Request is handed off to another Page
class. The Request is not changed.
The forms data then is in the Request object. Is using the Request object
a better solution than setting up the calling object to transfer the data
via
a series of get calls? Or is it just a matter of preference?
The difference between Server.Transfer and Response.Redire ct, is that
Response.Redir ect actually sends a Response back to the client browser,
telling it to request another URL. Therefore, the URL of the Request
changes, as it is actually a second Request from the client.
Server.Transfe r only changes the server-side handler of the current HTTP
Request.
Do you know if that causes any confusion for users? Using Redirect seems
to be a little inefficient?
Thanks, Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Hi Mike, So the default setting is true, is that is why setting it true seems to
have
no effect?
Correct.
The forms data then is in the Request object. Is using the Request object
a better solution than setting up the calling object to transfer the data
via
a series of get calls? Or is it just a matter of preference?
I'm having a little trouble understanding this one. Yes, the posted form
data is in the Request object. The Request object is created by parsing an
HTTP Request; in this case, the form POST Request from the Page.
Now, where I'm somewhat fuzzy is with the second part of the question. What
do you mean by "the calling object?" What do you mean by "setting up the
calling object to transfer data via a series of get calls?" Perhaps I can
explain a little bit (?) more of the technical aspect of this and answer
your question without understanding it fully.
The ASP.Net object model works in an HTTP environment. HTTP is a series of
client Requests and server Responses, kind of like a conversation between
client and server. But due to the stateless nature of HTTP, neither the
client nor the server can remember that previous message, or even that a
previous message was sent. Every HTTP Request/Response occurs "in a vacuum,"
so to speak. This is the primary reason why ASP.Net applications are
problematic to write. You want the server to have some memory of the context
of what is being done, in order to behave like an application. The way that
Microsoft has addressed this issue is via a set of mechanisms to emulate
state, and to maintain server state.
State can indeed be maintained on the server, in memory, in a database, via
any number of storage mechanisms. The trick is to associate the state with
each client, as the clients' Requests are not remembered after each Response
is sent. So, Application state, being global to the Application, is not a
problem. But client state is. The way that client state is maintained is
basically two-fold.
One is the use of the Request coming from the client. An HTTP Request can
include a certain amount of header data, QueryString data in the URL, form
data in form fields sent via POST, and any Cookies for that domain stored on
the client. The server can set cookies, which are returned with the
Response, and it can read the Cookies which are always included in the
client Request. Now, some Cookies are persistent, having an expiration
date/time in them, which causes them to be stored on the client's hard
drive. But Cookies without an expiration are referred to as "Session
Cookies." By default, they are stored only in the memory of the browser, and
expire when the browser navigates away from the web site, or closes. Many
browsers do not allow persistent Cookies, but most browsers do allow Session
Cookies. So, the first Request from the client causes the server to create a
memory space for that client, in a Collection stored in the Application,
which is called a Session. The Session is assigned a unique ID, and that ID
is sent as a Session Cookie to the client browser. From there, as long as
the client continues to send Requests, the Cookie makes round trips with
each Request/Response. Since the server is never notified that the client is
no longer there, it waits for 20 minutes for a Request, and if no Request is
received during that interval, it deletes the Session for that client,
freeing up memory on the server.
The other method for maintaining State is to pass data to the client, and
receive it back via Query String or form POST. Hence, you have the PostBack
model. This includes not only the form fields created by the Controls you
put into the page, but several hidden form fields, including a hidden form
field called "ViewState" that keeps track of the state of the Controls when
the last Response was sent to the client. When the user makes changes to the
form fields on the client, the values of these form fields are posted with
the Request, and the server compares them to the ViewState data to see what
has changed, and possibly respond to it.
Events are created by adding some JavaScript client-side event handlers that
put data into a couple of other hidden form fields, and then post the form
to the server. The server-side app looks at these hidden form fields to find
out what client-side events have occurred, and creates real server-side
Events to react to them.
All of this is built into the ASP.Net object model, and though you should be
aware of it, you generally don't have to think much about it; it handles
itself. It is important, though, to understand the object model, as well as
how HTTP works, in order to make intelligent choices about what to code on
the server.
So, now, we have the HTTP Request/Response, and we have 2
indirectly-connected applications, one on the client (the browser and the
HTML document loaded into it), and one on the server. It is the one on the
server that I want to discuss now, in order to hopefully answer your
question. Now, once the Request is received from the client, we are no
longer talking about Pages and Requests, and all that other client-side web
stuff; we are talking about a server application, which behaves on the
server just like any other application. Event though you have a class called
"System.Web.UI. Page," it isn't a "page" at all, or a document even. It is a
class. It is an executable business component. Any other System.Web.UI.P age
class on the server is also not a document, but a business entity in the
application. So, when you use Server.Transfer , you are simply calling on
another class to finish processing. You are transferring execution control
to another class.
Now, the Request object, as I said, is parsed from the HTTP Request received
from the client. It is not the same as the HTTP Request itself, which is
simply a text document. It is a class that contains data and process. The
data has been extracted from the HTTP Request, and the process is executable
code that can manipulate the data. It is the same with the HttpContext. The
HttpContext is a class that contains data and process extracted from the
HTTP Request, and from the web server. HTTP is no loger part of the
equation. The HTTP Request was sent, received from the client, parsed, and
classes were built from it. It then went the way of all flesh, disappearing
into the void. HTTP will not be a part of the equation again until the
server-side application hands off the finished HTML document, as a stream
containing text, to the web server again. At that point, the web server will
create an HTTP Response message to the client.
So, it's best to remember that, although these classes have names, and use
terms that are reminiscent of HTTP, they are not, in fact, doing anything at
all with HTTP. They are simply an application processing data.
Now, how does Response.Redire ct work? Simple. Rather than creating a full
HTML document, an HTTP Response with a "302" Status code is formed. The
"302" Status code indicates that a resource has moved temporarily to another
URL, and the Response header contains the other URL to Request. Again,
however, the Page class itself doesn't send the Response. It simply creates
it and hands it off to the web server.
So, on the server-side, there is no such thing as "transfer the data via a
series of get calls" on the server. There is no HTTP operating in the
ASP.Net application. When using Server.Transfer , program execution is simply
transferred to another class.
Now, as to when to use Response.Redire ct, and when to use Server.Tranfer,
well, you know of one reason already. The URL of the browser changes to the
new Page URL if you use Response.Redire ct. This is useful when you want to
treat the second Page class as if it is really another web page. Rembmber
that on the client, it *is* another web page. Using Server.Transfer , on the
other hand, is useful if you want to treat the HTML output of the second
Page class as if it was indeed part of the first Page, which was requested
by the client.
As for performance issues, yes, there is another Round-trip involved with
Response.Redire ct, but there are also any number of Round-trips associated
with the PostBack model. ASP.Net is designed to optimize server resources as
much as possible under this scenario. The only real issue is latency on the
client. But again, a Redirect Response is a very small HTTP message. In
other words, I wouldn't be concerned about it. I would be concerned instead
with which method is most appropriate in terms of how you want the app to
work.
Whew! I hope that helped!
Do you know if that causes any confusion for users? Using Redirect seems
to be a little inefficient?
After reading my explanation, I hope you can see why I said that the
"inefficien cy" of using Response.Redire ct should not be an issue. In fact,
you have put your finger on the button with this question. How do you want
the client user to perceive the Responses sent by your app?
Think of the client browser as a user interface, and the server-side app as
a set of business objects that interact with it remotely. Your goal, in
terms of the user interface, is to make it user-friendly. If you keep that
in mind, I don't think you'll have any trouble figuring out what to use and
when.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"Mike Gaab" <mi****@montana .com> wrote in message
news:11******** *****@spool6-east.superfeed. net...
"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Sure Mike,
When I use Server.Transfer ( "some.aspx" ) or
Server.Transfer ("some.aspx" , true), there doesn't seem to be any
difference in functionality. The docs say
Yes, the docs are a bit confusing. Setting the second parameter to false
is what clears the Collections.
So the default setting is true, is that is why setting it true seems to
have
no effect?
The docs also say that Server.Transfer stops execution of the previous webform. If that is the case, then how can I can a reference to it? I
guess I am thinking that stopping execution is
equivalent to destroy.
Exactly. It stops the previous Page class from continuing its execution.
The class is not destroyed. The difference is that the previous page is
no longer processing the Request. You have "transferre d" execution to the
new Page class.
One last thing, the URL in the browser still points to the calling
webform page.
That is true, and correct. Server.Transfer is a server-side transfer of
execution. The execution of the HTTP Request is handed off to another
Page class. The Request is not changed.
The forms data then is in the Request object. Is using the Request object
a better solution than setting up the calling object to transfer the data
via
a series of get calls? Or is it just a matter of preference?
The difference between Server.Transfer and Response.Redire ct, is that
Response.Redi rect actually sends a Response back to the client browser,
telling it to request another URL. Therefore, the URL of the Request
changes, as it is actually a second Request from the client.
Server.Transf er only changes the server-side handler of the current HTTP
Request.
Do you know if that causes any confusion for users? Using Redirect seems
to be a little inefficient?
Thanks, Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption
=----
"Spam Catcher" <sp**********@r ogers.com> wrote in message
news:Xn******** *************** ***********@127 .0.0.1... "Mike Gaab" <mi****@montana .com> wrote in
news:11******** *****@spool6-east.superfeed. net:
Does this mean your webpages have only one submit button per page?
No, you can have multiple submit buttons. Each submit button raises it's
own event handler.
Thanks, I totally overlooked that. I am still thinking as if I am
in the WAMP world.
Additional comment:
I am just not used to being limited to one form per page and how
ASP.Net passes form data to another webform page. For example,
since ASP.Net is emulating the desktop event model, one has to use
things like Server.Transfer to get form data to another page. This
just seems a little clunky. On the other hand, ASP.Net does some
really clever stuff that I enjoy very much.
Take a look at HTTPContext variables - they allow you to transfer data
from one page to another.
Like the Request object?
In most cases, you don't redirect directly to a second page in ASP.NET.
When you say "directly", are you referring to a form's action attribute?
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
"Spam Catcher" <sp**********@r ogers.com> wrote in message
news:Xn******** *************** ***********@127 .0.0.1... "Mike Gaab" <mi****@montana .com> wrote in
news:11******** *****@spool6-east.superfeed. net:
Take a look at HTTPContext variables - they allow you to transfer data
from one page to another.
How about a simple example...
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:ui******** *****@TK2MSFTNG P11.phx.gbl... I'm having a little trouble understanding this one. Yes, the posted form
data is in the Request object. The Request object is created by parsing an
HTTP Request; in this case, the form POST Request from the Page.
Now, where I'm somewhat fuzzy is with the second part of the question.
What do you mean by "the calling object?" What do you mean by "setting up
the calling object to transfer data via a series of get calls?"
this is where i got the idea http://www.codeproject.com/aspnet/Da...ingBtPages.asp
A WAMP scenrio:
1. User fills out an html form that contains a single textbox on Page A
2. Submits the html form on Page A to the server specifying the
SimpleAddition app to process the single textbox value.
3. The SimpleAddition app adds the value to itself and then returns that
value to the browser in Page B (with the browser showing that Page B was
returned).
How would you accomplish this simple task in webforms?
Thanks,
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =---- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: MarionEll |
last post by:
---------------------------------------------------------
************* Call for Participation **************
************ Late Breaking News *************
*********** Extreme Markup Languages 2003 ************
---------------------------------------------------------
The regular (peer reviewed) part of the Extreme 2003 program has
been scheduled. As usual, we have reserved a few slots on the
Extreme program for...
|
by: Philipp Lenssen |
last post by:
I would like to know what others do to prevent line-breaks, using
For example, the guidelines for the company have certain words (like
"Model XY", where "Model" and "XY" shouldn't be separated. Fair enough,
I use the non-breaking space for that.
How about things like:
- 10 to 100 KM/H
- 7 to 8 years
|
by: dan |
last post by:
Hi folks, I have a very simple requirement - I want to have a row of
divs of fixed size (but unknown number of them)
This will be in a container div and scrolled by other means
Is there any way of doing this so that the row is maintained and does
not break at the browser width? Typically IE does what I want....
although I gather its "wrong" on the specs.
I can see myself ending up using a table, which spoils some other plans
|
by: Frances Del Rio |
last post by:
is there a non-breaking hyphen in HTML?? for example, so a phone no.
falls all on one line.. as in..
1-800-444-5454... (and is not broken into two lines if phone no. occurs
near end of a line..)
(searched for 'hyphen' in FAQ pg, didn't find anything..)
thank you.. Frances
|
by: The Bicycling Guitarist |
last post by:
Hi. I found the following when trying to learn if there is such a thing as a
non-breaking hyphen. Apparently Unicode has a ‑ but that is not
well-supported, especially in older browsers. Somebody somewhere said:
Alternately, you can use CSS to declare a class having:
..nowrap { white-space:nowrap }
.... and then wrap the compound word in a <span class=nowrap></span> tag (or
any other suitable inline tag). You can also try {...
| | |
by: stevenkobes |
last post by:
If a word has a hyphen in it, IE will permit a line break at the
hyphen, but Firefox/Mozilla won't. Apparently the Firefox behavior is
standards-compliant, but it is not what I want. Is there a way to
denote a hyphen in HTML, that the line can be broken after?
I've read some stuff about soft hyphens and non-breaking hyphens, but
those seem like the opposite of what I'm looking for. I want a normal
hyphen, that always appears, and I...
|
by: John Wood |
last post by:
I saw that Microsoft have released a list of breaking changes in .Net here:
http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/default.aspx
While this is useful, it seems to be missing a change that has broken a lot
of my applications, relating to the order in which members are returned by
reflection. At least I can't find it. I reported the bug on ladybug:...
|
by: Frank Rizzo |
last post by:
I will soon be deploying an application on Windows 2003 R2 64-bit
Standard Edition. The app will also be compiled for 64-bit. One of the
reasons is that the application will really benefit from having more
than 2GB available to it.
The
http://www.microsoft.com/windowsserver2003/evaluation/features/comparefeatures.mspx
page states that Windows 2003 R2 64-bit Standard Edition can handle up
to 32GB of RAM. My question is whether anyone...
|
by: PB |
last post by:
Hi,
I need some CSS layout guidance because I think I've been staring at
this too long!
I designed my layout using Photoshop, then sliced everything up and
saved as a CSS web page.
My problem arises when I started re-coding the html and CSS. My
graphics begin to break up at the bottom with large gaps and wrong
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
