FrontPage Server Extensions for Windows - Strange FP components behaviour on server

Author

Strange FP components behaviour on server

DeltaGamma

2004-10-16, 5:52 pm

Have published a web to a 2002 server, initially with FP2K, and now also with
FP03. There are several components that do not appear to work correctly, eg:

1) Have many forms, all of which had worked at one time. All but one work
on the new installation (including forms in subwebs etc). However one form on
returns a "partial" email response on "submit". That is, it essentially only
sends (approx) half of the fieldnames and fieldvalues that have been selected
in the save fields dialog. Sometimes, the fieldvalues have what appear to be
html tag snippets. There are approx 60 fields/values saved (most are
checkboxes), and only about 30 are returned. Deleting field from the form
improves the result, and essentially all fields are obtained when about 30
are deleted. Though there is still some weirdness in that sometimes there is
"blank" inserted into the fieldnames.

How is it possible to get the full form returned (as it was possible before)?

2) The FP counters will not accept an "overwrite". E.g. in component
properties there is a field wherein to update the current counter values, and
altering this has no effect on the server side. Nor does the server care if
there is direct editing of the cnt file on the client side. Eventually
forced overwrite with ftp upload of cnt files, but ???

3) The update Date in the bottom border does not update (on the server side,
but does on the client side) when the body of a page is edited. However,
when the bottom border is edited (e.g. add a space) then it updates the
server as well, though now globally all pages' dates are brute force
overwritten.

Is it possible that all of these issues are FP extension related? Does it
make any difference that the site was produced originally in FP2K but is now
under FP03?

Ronx

2004-10-16, 5:52 pm

Inline below

--
Ron Symonds (Microsoft MVP - FrontPage)
Reply only to group - emails will be deleted unread.

"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
> Have published a web to a 2002 server, initially with FP2K, and now also
> with
> FP03. There are several components that do not appear to work correctly,
> eg:
>
> 1) Have many forms, all of which had worked at one time. All but one work
> on the new installation (including forms in subwebs etc). However one form
> on
> returns a "partial" email response on "submit". That is, it essentially
> only
> sends (approx) half of the fieldnames and fieldvalues that have been
> selected
> in the save fields dialog. Sometimes, the fieldvalues have what appear to
> be
> html tag snippets. There are approx 60 fields/values saved (most are
> checkboxes), and only about 30 are returned. Deleting field from the
> form
> improves the result, and essentially all fields are obtained when about 30
> are deleted. Though there is still some weirdness in that sometimes there
> is
> "blank" inserted into the fieldnames.
>
> How is it possible to get the full form returned (as it was possible
> before)?

If the email is not formatted as "formatted text" it is possible that some
fields will not be included in the email. Formatted Text usually sends the
entire form.

>
> 2) The FP counters will not accept an "overwrite". E.g. in component
> properties there is a field wherein to update the current counter values,
> and
> altering this has no effect on the server side. Nor does the server care
> if
> there is direct editing of the cnt file on the client side. Eventually
> forced overwrite with ftp upload of cnt files, but ???

The local copy of the .cnt files are not normally published. If they were
the counters on the server would be reset with every publish. Open the web
on the server and update the counter properties there.

>
> 3) The update Date in the bottom border does not update (on the server
> side,
> but does on the client side) when the body of a page is edited. However,
> when the bottom border is edited (e.g. add a space) then it updates the
> server as well, though now globally all pages' dates are brute force
> overwritten.

Set the properties on the time stamp to "Date this page was last
automatically updated".
This will set the date/time to when any shared border or the content on the
page is changed, whichever is the later.

> Is it possible that all of these issues are FP extension related? Does it
> make any difference that the site was produced originally in FP2K but is
> now
> under FP03?

Makes no difference

DeltaGamma

2004-10-16, 5:52 pm

Thank you for all those points, I add some questions/comments below, though
there is a "big picture" issue - am I just seeing some quirks due to
"upgrading" to FP03, or is it possible that all of these issues are FP
extensions (and so server side) related?

"Ronx" wrote:

> Inline below
>
> --
> Ron Symonds (Microsoft MVP - FrontPage)
> Reply only to group - emails will be deleted unread.
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
>
> If the email is not formatted as "formatted text" it is possible that some
> fields will not be included in the email. Formatted Text usually sends the
> entire form.
>
The forms email results are in "HTML" format (and have been for some years).
This all used to work at an earlier data (and a different server). Also,
there is definitely a "size" issues, since adding or removing items appears
to have an effect. Moreover, there is added strangness of the "tags" etc as
described above. A bit confusing, really.

>
> The local copy of the .cnt files are not normally published. If they were
> the counters on the server would be reset with every publish. Open the web
> on the server and update the counter properties there.

OK but at least in FP2K I could (within FP) edit component properties,
change the "starging number" (i.e. the "reset counter to" field), and that
would work. But now in FP03 it does not! I cant even tell if that is an
FP03 client side problem, or an FP2002 server side problem (e.g.
extensions??), any thoughts?
>
>
> Set the properties on the time stamp to "Date this page was last
> automatically updated".
> This will set the date/time to when any shared border or the content on the
> page is changed, whichever is the later.
>
>
> Makes no difference

Sorry, I dont follow the "makes no difference". Is that to mean that it
wont work regardless of the FP version. Since at one time this sort of thing
did work, and the update Dates were correctly managed by FP on both the
client and server (where as now its only the client).

Also, as a basic rule, pretty much everytime we edit the site "live" it can
lead to very very catastrophic problems, not to mention that such an approach
makes "version control" a bit of a 'mare. So we just dont do it as a matter
of policy (short of an act of God).
>
>
>

Ronx

2004-10-16, 5:52 pm

inline

--
Ron Symonds (Microsoft MVP - FrontPage)
Reply only to group - emails will be deleted unread.

"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
> Thank you for all those points, I add some questions/comments below,
> though
> there is a "big picture" issue - am I just seeing some quirks due to
> "upgrading" to FP03, or is it possible that all of these issues are FP
> extensions (and so server side) related?

The quirks are more related to the extensions than to FP03. As far as I
remember, these quirks have been present ever since FP2002 extensions. I do
not remember them with FP2000 extensions. I do not use FrontPage forms or
counters on my sites, so I cannot answer from personal experience, just what
I have picked up in these newsgroups.

>
> "Ronx" wrote:
>
> The forms email results are in "HTML" format (and have been for some
> years).
> This all used to work at an earlier data (and a different server). Also,
> there is definitely a "size" issues, since adding or removing items
> appears
> to have an effect. Moreover, there is added strangness of the "tags" etc
> as
> described above. A bit confusing, really.

Did the previous server use FP2000 extensions?
With the FP2002 extensions, HTML formatting does introduce a size issue.
Its related both to the quantity of data being processed and the number of
fields.
The HTML tags may be another facet of the problem, but I have never seen
this before.

>
> OK but at least in FP2K I could (within FP) edit component properties,
> change the "starging number" (i.e. the "reset counter to" field), and that
> would work. But now in FP03 it does not! I cant even tell if that is an
> FP03 client side problem, or an FP2002 server side problem (e.g.
> extensions??), any thoughts?

In the local web, are the .cnt marked as "Do not publish" (a red circle on
the file icon). This is the normal state for these files to prevent
publishing and over-writing the files on the server. You can remove this
restriction, publish, and change them back. I never recommend this method
since too many users forget that last step and wonder why their counters
keep resetting every time they publish.

I just tried this on my test system, and it made no difference to the server
side counter. Explanation: The Home page (where I put the counter) name on
the server was changed to Default.htm (from index.htm) when I published the
web, but the .cnt file was published as index.htm.cnt, with no name change.
Another reason for the unwary to edit on the server.

>
> Sorry, I dont follow the "makes no difference". Is that to mean that it
> wont work regardless of the FP version. Since at one time this sort of
> thing
> did work, and the update Dates were correctly managed by FP on both the
> client and server (where as now its only the client).

If the timestamp properties are set as described, the update dates are
managed at both ends as you want them to be. It could be that the default
setting in FP2000 was the "...automatic ..." setting (its been three years
since I used FP2000).

Except as mentioned above, the version of FrontPage client makes no
difference. However, it is possible that the version of FrontPage
extensions does.

> Also, as a basic rule, pretty much everytime we edit the site "live" it
> can
> lead to very very catastrophic problems, not to mention that such an
> approach
> makes "version control" a bit of a 'mare. So we just dont do it as a
> matter
> of policy (short of an act of God).

I will not argue with that policy, I use it myself, though not so rigidly.
But some things must be done on the server, such as changing permissions in
folders, and some things are more easily done on the server than locally,
such as resetting counters (which would rarely be the same on the local web,
anyway).

DeltaGamma

2004-10-16, 8:47 pm

OK, thanks for the extended effort, though it sounds like we are in a bit of
mess then, since it seems that there is nothing that we can do about it (at
least in FP03/2002Server mode).

I suppose it’s the usual giant size madness of "upgrading" for so-called
benefits, but having to learn from scratch all manner of new bugs and
idiosyncrasies. Frankly, we did not wish to upgrade to 03 (and in general
our experience is that upgrading is absurdly expensive from a cost of
ownership perspective), but somebody provided us with compelling arguments
for it in this case … silly us … we believed it.

I must say that all of us here very much prefer FP2K for the most part, and
may seek to reverse the upgrade process. Its just too expensive having to
deal with nonsense like incompatible syntax, or otherwise working facilities
failing in the new environment (and not knowing why, but requiring huge
costs). Though I can see that it’s a great "make work project" for IT
consultants, unfortunately its ruinously expensive for small businesses.

Why cant new versions offer the “true” backward compatibility, and why cant
new versions offer “classic skins”. We understand it takes some
(experienced) people 3 weeks to transition from FP2K to FP03 just because MS
has moved things around, renamed them, hidden them, etc. Imagine if you (or
B Gates) came to work and you (or BG) were not paid for three weeks, how
would that feel?

A real shame that nobody cares about the true cost and what deleterious
effect it has on the livelihood of many.

Would you be so kind to pass these comments on to somebody in your firm
(perhaps someone who may have some power to do some good with it)?

"Ronx" wrote:

> inline
>
> --
> Ron Symonds (Microsoft MVP - FrontPage)
> Reply only to group - emails will be deleted unread.
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
>
> The quirks are more related to the extensions than to FP03. As far as I
> remember, these quirks have been present ever since FP2002 extensions. I do
> not remember them with FP2000 extensions. I do not use FrontPage forms or
> counters on my sites, so I cannot answer from personal experience, just what
> I have picked up in these newsgroups.
>
>
> Did the previous server use FP2000 extensions?
> With the FP2002 extensions, HTML formatting does introduce a size issue.
> Its related both to the quantity of data being processed and the number of
> fields.
> The HTML tags may be another facet of the problem, but I have never seen
> this before.
>
>
> In the local web, are the .cnt marked as "Do not publish" (a red circle on
> the file icon). This is the normal state for these files to prevent
> publishing and over-writing the files on the server. You can remove this
> restriction, publish, and change them back. I never recommend this method
> since too many users forget that last step and wonder why their counters
> keep resetting every time they publish.
>
> I just tried this on my test system, and it made no difference to the server
> side counter. Explanation: The Home page (where I put the counter) name on
> the server was changed to Default.htm (from index.htm) when I published the
> web, but the .cnt file was published as index.htm.cnt, with no name change.
> Another reason for the unwary to edit on the server.
>
>
> If the timestamp properties are set as described, the update dates are
> managed at both ends as you want them to be. It could be that the default
> setting in FP2000 was the "...automatic ..." setting (its been three years
> since I used FP2000).
>
> Except as mentioned above, the version of FrontPage client makes no
> difference. However, it is possible that the version of FrontPage
> extensions does.
>
>
> I will not argue with that policy, I use it myself, though not so rigidly.
> But some things must be done on the server, such as changing permissions in
> folders, and some things are more easily done on the server than locally,
> such as resetting counters (which would rarely be the same on the local web,
> anyway).
>
>
>

Ronx

2004-10-17, 7:47 am

>Would you be so kind to pass these comments on to somebody in your firm
>(perhaps someone who may have some power to do some good with it)?

Not possible

- I retired 4 years ago, and have never worked for
Microsoft, anyway.

The Microsoft Wish Program can be reached from here:
http://support.microsoft.com/default.aspx?kbid=114491

--
Ron Symonds (Microsoft MVP - FrontPage)
Reply only to group - emails will be deleted unread.

"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
news:CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...[vbcol=seagreen]
>
> OK, thanks for the extended effort, though it sounds like we are in a bit
> of
> mess then, since it seems that there is nothing that we can do about it
> (at
> least in FP03/2002Server mode).
>
> I suppose it’s the usual giant size madness of "upgrading" for so-called
> benefits, but having to learn from scratch all manner of new bugs and
> idiosyncrasies. Frankly, we did not wish to upgrade to 03 (and in general
> our experience is that upgrading is absurdly expensive from a cost of
> ownership perspective), but somebody provided us with compelling arguments
> for it in this case … silly us … we believed it.
>
> I must say that all of us here very much prefer FP2K for the most part,
> and
> may seek to reverse the upgrade process. Its just too expensive having to
> deal with nonsense like incompatible syntax, or otherwise working
> facilities
> failing in the new environment (and not knowing why, but requiring huge
> costs). Though I can see that it’s a great "make work project" for IT
> consultants, unfortunately its ruinously expensive for small businesses.
>
> Why cant new versions offer the “true” backward compatibility, and why
> cant
> new versions offer “classic skins”. We understand it takes some
> (experienced) people 3 weeks to transition from FP2K to FP03 just because
> MS
> has moved things around, renamed them, hidden them, etc. Imagine if you
> (or
> B Gates) came to work and you (or BG) were not paid for three weeks, how
> would that feel?
>
> A real shame that nobody cares about the true cost and what deleterious
> effect it has on the livelihood of many.
>
> Would you be so kind to pass these comments on to somebody in your firm
> (perhaps someone who may have some power to do some good with it)?
>
> "Ronx" wrote:
>

Stefan B Rusynko

2004-10-17, 7:47 am

There is FP SE issue w/ long forms - See
http://support.microsoft.com/defaul...&Product=fp10se

--

________________________________________
_____
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.net-sites.com/sitebuilder/newsgroups.asp
________________________________________
_____

"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message news:CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...
|
| OK, thanks for the extended effort, though it sounds like we are in a bit of
| mess then, since it seems that there is nothing that we can do about it (at
| least in FP03/2002Server mode).
|
| I suppose it’s the usual giant size madness of "upgrading" for so-called
| benefits, but having to learn from scratch all manner of new bugs and
| idiosyncrasies. Frankly, we did not wish to upgrade to 03 (and in general
| our experience is that upgrading is absurdly expensive from a cost of
| ownership perspective), but somebody provided us with compelling arguments
| for it in this case … silly us … we believed it.
|
| I must say that all of us here very much prefer FP2K for the most part, and
| may seek to reverse the upgrade process. Its just too expensive having to
| deal with nonsense like incompatible syntax, or otherwise working facilities
| failing in the new environment (and not knowing why, but requiring huge
| costs). Though I can see that it’s a great "make work project" for IT
| consultants, unfortunately its ruinously expensive for small businesses.
|
| Why cant new versions offer the “true” backward compatibility, and why cant
| new versions offer “classic skins”. We understand it takes some
| (experienced) people 3 weeks to transition from FP2K to FP03 just because MS
| has moved things around, renamed them, hidden them, etc. Imagine if you (or
| B Gates) came to work and you (or BG) were not paid for three weeks, how
| would that feel?
|
| A real shame that nobody cares about the true cost and what deleterious
| effect it has on the livelihood of many.
|
| Would you be so kind to pass these comments on to somebody in your firm
| (perhaps someone who may have some power to do some good with it)?
|
| "Ronx" wrote:
|
| > inline
| >
| > --
| > Ron Symonds (Microsoft MVP - FrontPage)
| > Reply only to group - emails will be deleted unread.
| >
| >
| > "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
| > news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
| > > Thank you for all those points, I add some questions/comments below,
| > > though
| > > there is a "big picture" issue - am I just seeing some quirks due to
| > > "upgrading" to FP03, or is it possible that all of these issues are FP
| > > extensions (and so server side) related?
| >
| > The quirks are more related to the extensions than to FP03. As far as I
| > remember, these quirks have been present ever since FP2002 extensions. I do
| > not remember them with FP2000 extensions. I do not use FrontPage forms or
| > counters on my sites, so I cannot answer from personal experience, just what
| > I have picked up in these newsgroups.
| >
| > >
| > > "Ronx" wrote:
| > >
| > >> Inline below
| > >>
| > >> --
| > >> Ron Symonds (Microsoft MVP - FrontPage)
| > >> Reply only to group - emails will be deleted unread.
| > >>
| > >>
| > >> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
| > >> news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
| > >> > Have published a web to a 2002 server, initially with FP2K, and now
| > >> > also
| > >> > with
| > >> > FP03. There are several components that do not appear to work
| > >> > correctly,
| > >> > eg:
| > >> >
| > >> > 1) Have many forms, all of which had worked at one time. All but one
| > >> > work
| > >> > on the new installation (including forms in subwebs etc). However one
| > >> > form
| > >> > on
| > >> > returns a "partial" email response on "submit". That is, it
| > >> > essentially
| > >> > only
| > >> > sends (approx) half of the fieldnames and fieldvalues that have been
| > >> > selected
| > >> > in the save fields dialog. Sometimes, the fieldvalues have what appear
| > >> > to
| > >> > be
| > >> > html tag snippets. There are approx 60 fields/values saved (most are
| > >> > checkboxes), and only about 30 are returned. Deleting field from the
| > >> > form
| > >> > improves the result, and essentially all fields are obtained when about
| > >> > 30
| > >> > are deleted. Though there is still some weirdness in that sometimes
| > >> > there
| > >> > is
| > >> > "blank" inserted into the fieldnames.
| > >> >
| > >> > How is it possible to get the full form returned (as it was possible
| > >> > before)?
| > >>
| > >> If the email is not formatted as "formatted text" it is possible that
| > >> some
| > >> fields will not be included in the email. Formatted Text usually sends
| > >> the
| > >> entire form.
| > >>
| > > The forms email results are in "HTML" format (and have been for some
| > > years).
| > > This all used to work at an earlier data (and a different server). Also,
| > > there is definitely a "size" issues, since adding or removing items
| > > appears
| > > to have an effect. Moreover, there is added strangness of the "tags" etc
| > > as
| > > described above. A bit confusing, really.
| >
| > Did the previous server use FP2000 extensions?
| > With the FP2002 extensions, HTML formatting does introduce a size issue.
| > Its related both to the quantity of data being processed and the number of
| > fields.
| > The HTML tags may be another facet of the problem, but I have never seen
| > this before.
| >
| > >> >
| > >> > 2) The FP counters will not accept an "overwrite". E.g. in component
| > >> > properties there is a field wherein to update the current counter
| > >> > values,
| > >> > and
| > >> > altering this has no effect on the server side. Nor does the server
| > >> > care
| > >> > if
| > >> > there is direct editing of the cnt file on the client side. Eventually
| > >> > forced overwrite with ftp upload of cnt files, but ???
| > >>
| > >> The local copy of the .cnt files are not normally published. If they
| > >> were
| > >> the counters on the server would be reset with every publish. Open the
| > >> web
| > >> on the server and update the counter properties there.
| > >
| > > OK but at least in FP2K I could (within FP) edit component properties,
| > > change the "starging number" (i.e. the "reset counter to" field), and that
| > > would work. But now in FP03 it does not! I cant even tell if that is an
| > > FP03 client side problem, or an FP2002 server side problem (e.g.
| > > extensions??), any thoughts?
| >
| > In the local web, are the .cnt marked as "Do not publish" (a red circle on
| > the file icon). This is the normal state for these files to prevent
| > publishing and over-writing the files on the server. You can remove this
| > restriction, publish, and change them back. I never recommend this method
| > since too many users forget that last step and wonder why their counters
| > keep resetting every time they publish.
| >
| > I just tried this on my test system, and it made no difference to the server
| > side counter. Explanation: The Home page (where I put the counter) name on
| > the server was changed to Default.htm (from index.htm) when I published the
| > web, but the .cnt file was published as index.htm.cnt, with no name change.
| > Another reason for the unwary to edit on the server.
| >
| > >>
| > >> >
| > >> > 3) The update Date in the bottom border does not update (on the server
| > >> > side,
| > >> > but does on the client side) when the body of a page is edited.
| > >> > However,
| > >> > when the bottom border is edited (e.g. add a space) then it updates the
| > >> > server as well, though now globally all pages' dates are brute force
| > >> > overwritten.
| > >>
| > >> Set the properties on the time stamp to "Date this page was last
| > >> automatically updated".
| > >> This will set the date/time to when any shared border or the content on
| > >> the
| > >> page is changed, whichever is the later.
| > >>
| > >> > Is it possible that all of these issues are FP extension related? Does
| > >> > it
| > >> > make any difference that the site was produced originally in FP2K but
| > >> > is
| > >> > now
| > >> > under FP03?
| > >>
| > >> Makes no difference
| > >
| > > Sorry, I dont follow the "makes no difference". Is that to mean that it
| > > wont work regardless of the FP version. Since at one time this sort of
| > > thing
| > > did work, and the update Dates were correctly managed by FP on both the
| > > client and server (where as now its only the client).
| >
| > If the timestamp properties are set as described, the update dates are
| > managed at both ends as you want them to be. It could be that the default
| > setting in FP2000 was the "...automatic ..." setting (its been three years
| > since I used FP2000).
| >
| > Except as mentioned above, the version of FrontPage client makes no
| > difference. However, it is possible that the version of FrontPage
| > extensions does.
| >
| > > Also, as a basic rule, pretty much everytime we edit the site "live" it
| > > can
| > > lead to very very catastrophic problems, not to mention that such an
| > > approach
| > > makes "version control" a bit of a 'mare. So we just dont do it as a
| > > matter
| > > of policy (short of an act of God).
| >
| > I will not argue with that policy, I use it myself, though not so rigidly.
| > But some things must be done on the server, such as changing permissions in
| > folders, and some things are more easily done on the server than locally,
| > such as resetting counters (which would rarely be the same on the local web,
| > anyway).
| >
| >
| >

DeltaGamma

2004-10-17, 5:49 pm

My apologies, though in the thread it has "Ron Symonds (Microsoft MVP -
FrontPage)" and so I hope you will forgive any confusion by the (strong)
implication of that title.

"Ronx" wrote:

>
> Not possible

- I retired 4 years ago, and have never worked for
> Microsoft, anyway.
>
> The Microsoft Wish Program can be reached from here:
> http://support.microsoft.com/default.aspx?kbid=114491
>
> --
> Ron Symonds (Microsoft MVP - FrontPage)
> Reply only to group - emails will be deleted unread.
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> news:CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...
>
>
>

Stefan B Rusynko

2004-10-18, 2:50 am

See http://mvp.support.microsoft.com/de...csum&style=flat

--

________________________________________
_____
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.net-sites.com/sitebuilder/newsgroups.asp
________________________________________
_____

"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message news:CC0ED518-EC0B-46C1-ABAB-76B65444D739@microsoft.com...
| My apologies, though in the thread it has "Ron Symonds (Microsoft MVP -
| FrontPage)" and so I hope you will forgive any confusion by the (strong)
| implication of that title.
|
| "Ronx" wrote:
|
| > >Would you be so kind to pass these comments on to somebody in your firm
| > >(perhaps someone who may have some power to do some good with it)?
| >
| > Not possible

DeltaGamma

2004-10-18, 8:47 pm

Thanks for that, spoke with ISP, they say that all of their facilities are
already compliant with the points in that support link ... not really sure
what to do now ... we have informed that re-writing the page from scratch in
FP03 should resolve it, but this did not work either, and in any case
rewriting hundreds of (complex) pages from scratch (just to upgrade from 2k
to 03 seems) is ruinously expensive.

"Stefan B Rusynko" wrote:

> There is FP SE issue w/ long forms - See
> http://support.microsoft.com/defaul...&Product=fp10se
>
> --
>
> ________________________________________
_____
> SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
> "Warning - Using the F1 Key will not break anything!" (-;
> To find the best Newsgroup for FrontPage support see:
> http://www.net-sites.com/sitebuilder/newsgroups.asp
> ________________________________________
_____
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message news:CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...
> |
> | OK, thanks for the extended effort, though it sounds like we are in a bit of
> | mess then, since it seems that there is nothing that we can do about it (at
> | least in FP03/2002Server mode).
> |
> | I suppose itâ€™s the usual giant size madness of "upgrading" for so-called
> | benefits, but having to learn from scratch all manner of new bugs and
> | idiosyncrasies. Frankly, we did not wish to upgrade to 03 (and in general
> | our experience is that upgrading is absurdly expensive from a cost of
> | ownership perspective), but somebody provided us with compelling arguments
> | for it in this case â€¦ silly us â€¦ we believed it.
> |
> | I must say that all of us here very much prefer FP2K for the most part, and
> | may seek to reverse the upgrade process. Its just too expensive having to
> | deal with nonsense like incompatible syntax, or otherwise working facilities
> | failing in the new environment (and not knowing why, but requiring huge
> | costs). Though I can see that itâ€™s a great "make work project" for IT
> | consultants, unfortunately its ruinously expensive for small businesses.
> |
> | Why cant new versions offer the â€œtrueâ€ backward compatibility, and why cant
> | new versions offer â€œclassic skinsâ€. We understand it takes some
> | (experienced) people 3 weeks to transition from FP2K to FP03 just because MS
> | has moved things around, renamed them, hidden them, etc. Imagine if you (or
> | B Gates) came to work and you (or BG) were not paid for three weeks, how
> | would that feel?
> |
> | A real shame that nobody cares about the true cost and what deleterious
> | effect it has on the livelihood of many.
> |
> | Would you be so kind to pass these comments on to somebody in your firm
> | (perhaps someone who may have some power to do some good with it)?
> |
> | "Ronx" wrote:
> |
> | > inline
> | >
> | > --
> | > Ron Symonds (Microsoft MVP - FrontPage)
> | > Reply only to group - emails will be deleted unread.
> | >
> | >
> | > "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> | > news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
> | > > Thank you for all those points, I add some questions/comments below,
> | > > though
> | > > there is a "big picture" issue - am I just seeing some quirks due to
> | > > "upgrading" to FP03, or is it possible that all of these issues are FP
> | > > extensions (and so server side) related?
> | >
> | > The quirks are more related to the extensions than to FP03. As far as I
> | > remember, these quirks have been present ever since FP2002 extensions. I do
> | > not remember them with FP2000 extensions. I do not use FrontPage forms or
> | > counters on my sites, so I cannot answer from personal experience, just what
> | > I have picked up in these newsgroups.
> | >
> | > >
> | > > "Ronx" wrote:
> | > >
> | > >> Inline below
> | > >>
> | > >> --
> | > >> Ron Symonds (Microsoft MVP - FrontPage)
> | > >> Reply only to group - emails will be deleted unread.
> | > >>
> | > >>
> | > >> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> | > >> news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
> | > >> > Have published a web to a 2002 server, initially with FP2K, and now
> | > >> > also
> | > >> > with
> | > >> > FP03. There are several components that do not appear to work
> | > >> > correctly,
> | > >> > eg:
> | > >> >
> | > >> > 1) Have many forms, all of which had worked at one time. All but one
> | > >> > work
> | > >> > on the new installation (including forms in subwebs etc). However one
> | > >> > form
> | > >> > on
> | > >> > returns a "partial" email response on "submit". That is, it
> | > >> > essentially
> | > >> > only
> | > >> > sends (approx) half of the fieldnames and fieldvalues that have been
> | > >> > selected
> | > >> > in the save fields dialog. Sometimes, the fieldvalues have what appear
> | > >> > to
> | > >> > be
> | > >> > html tag snippets. There are approx 60 fields/values saved (most are
> | > >> > checkboxes), and only about 30 are returned. Deleting field from the
> | > >> > form
> | > >> > improves the result, and essentially all fields are obtained when about
> | > >> > 30
> | > >> > are deleted. Though there is still some weirdness in that sometimes
> | > >> > there
> | > >> > is
> | > >> > "blank" inserted into the fieldnames.
> | > >> >
> | > >> > How is it possible to get the full form returned (as it was possible
> | > >> > before)?
> | > >>
> | > >> If the email is not formatted as "formatted text" it is possible that
> | > >> some
> | > >> fields will not be included in the email. Formatted Text usually sends
> | > >> the
> | > >> entire form.
> | > >>
> | > > The forms email results are in "HTML" format (and have been for some
> | > > years).
> | > > This all used to work at an earlier data (and a different server). Also,
> | > > there is definitely a "size" issues, since adding or removing items
> | > > appears
> | > > to have an effect. Moreover, there is added strangness of the "tags" etc
> | > > as
> | > > described above. A bit confusing, really.
> | >
> | > Did the previous server use FP2000 extensions?
> | > With the FP2002 extensions, HTML formatting does introduce a size issue.
> | > Its related both to the quantity of data being processed and the number of
> | > fields.
> | > The HTML tags may be another facet of the problem, but I have never seen
> | > this before.
> | >
> | > >> >
> | > >> > 2) The FP counters will not accept an "overwrite". E.g. in component
> | > >> > properties there is a field wherein to update the current counter
> | > >> > values,
> | > >> > and
> | > >> > altering this has no effect on the server side. Nor does the server
> | > >> > care
> | > >> > if
> | > >> > there is direct editing of the cnt file on the client side. Eventually
> | > >> > forced overwrite with ftp upload of cnt files, but ???
> | > >>
> | > >> The local copy of the .cnt files are not normally published. If they
> | > >> were
> | > >> the counters on the server would be reset with every publish. Open the
> | > >> web
> | > >> on the server and update the counter properties there.
> | > >
> | > > OK but at least in FP2K I could (within FP) edit component properties,
> | > > change the "starging number" (i.e. the "reset counter to" field), and that
> | > > would work. But now in FP03 it does not! I cant even tell if that is an
> | > > FP03 client side problem, or an FP2002 server side problem (e.g.
> | > > extensions??), any thoughts?
> | >
> | > In the local web, are the .cnt marked as "Do not publish" (a red circle on
> | > the file icon). This is the normal state for these files to prevent
> | > publishing and over-writing the files on the server. You can remove this
> | > restriction, publish, and change them back. I never recommend this method
> | > since too many users forget that last step and wonder why their counters
> | > keep resetting every time they publish.
> | >
> | > I just tried this on my test system, and it made no difference to the server
> | > side counter. Explanation: The Home page (where I put the counter) name on
> | > the server was changed to Default.htm (from index.htm) when I published the
> | > web, but the .cnt file was published as index.htm.cnt, with no name change.
> | > Another reason for the unwary to edit on the server.
> | >
> | > >>
> | > >> >
> | > >> > 3) The update Date in the bottom border does not update (on the server
> | > >> > side,
> | > >> > but does on the client side) when the body of a page is edited.
> | > >> > However,
> | > >> > when the bottom border is edited (e.g. add a space) then it updates the
> | > >> > server as well, though now globally all pages' dates are brute force
> | > >> > overwritten.
> | > >>
> | > >> Set the properties on the time stamp to "Date this page was last
> | > >> automatically updated".
> | > >> This will set the date/time to when any shared border or the content on
> | > >> the
> | > >> page is changed, whichever is the later.
> | > >>
> | > >> > Is it possible that all of these issues are FP extension related? Does
> | > >> > it
> | > >> > make any difference that the site was produced originally in FP2K but
> | > >> > is
> | > >> > now
> | > >> > under FP03?
> | > >>
> | > >> Makes no difference
> | > >
> | > > Sorry, I dont follow the "makes no difference". Is that to mean that it
> | > > wont work regardless of the FP version. Since at one time this sort of
> | > > thing
> | > > did work, and the update Dates were correctly managed by FP on both the
> | > > client and server (where as now its only the client).
> | >
> | > If the timestamp properties are set as described, the update dates are
> | > managed at both ends as you want them to be. It could be that the default
> | > setting in FP2000 was the "...automatic ..." setting (its been three years
> | > since I used FP2000).
> | >
> | > Except as mentioned above, the version of FrontPage client makes no
> | > difference. However, it is possible that the version of FrontPage
> | > extensions does.
> | >
> | > > Also, as a basic rule, pretty much everytime we edit the site "live" it
> | > > can
> | > > lead to very very catastrophic problems, not to mention that such an
> | > > approach
> | > > makes "version control" a bit of a 'mare. So we just dont do it as a
> | > > matter
> | > > of policy (short of an act of God).
> | >
> | > I will not argue with that policy, I use it myself, though not so rigidly.
> | > But some things must be done on the server, such as changing permissions in
> | > folders, and some things are more easily done on the server than locally,
> | > such as resetting counters (which would rarely be the same on the local web,
> | > anyway).
> | >
> | >
> | >
>
>
>