RE: Could not find schema information

[Greg Keogh]

>xsd will create a schema from your xml.
>Is that what you want?   



It turns out the tool was under my nose all the time. In the VS2008 XML menu
it's the first selection. Although it produces strange results unless your
Xml file is a good example for it to go by.

 

>What benefit does having a schema for a config file give you?

 

As I said, to get rid of compile Messages. I see many other people have
complained of this also. I have lots of other XML files in my projects as
well, and they will also generate thousands of build Messages if they are
open when the build fails.



>Mayby you want something like csd.codeplex.com ?

 

Hmm! Interesting and technically advanced, but overkill for my modest needs.

 

Greg

Re: Permission denied

[Mark Kemper]

Could there be a active directory issue?


On 13/05/2010, at 11:24, Dylan Tusler > wrote:


We've suddenly (this week) started getting "Permission denied"  
errors on some of our internal websites (page loads fine, but a  
little "Error on page." appears in the bottom  left corner, and  
behind it is a "Permission Denied" error. Some functionality doesn't  
work, specifically it appears to be choking on a JavaScript POST to  
another page on the same site.)


Also, a number of users are reporting that they are being prompted  
to log in to web pages that previously never prompted for credentials.


One site in particular is heavily affected, and looking at the site,  
I can't see anything  having changed (no web.config changes, no  
permissions changes, etc.)


I've looked at everything I can think of, including running ethereal  
traces and logging vast amounts of procmon logs. Nothing untoward  
appears that I can see.


Can anyone take a stab at what might be going on? I'm just getting  
frustrated with it.


Cheers
Dylan Tusler



--- 
--- 
--- 
--- 
--- 
--- 
--- 
--- 
--- 
--
To find out more about the Sunshine Coast Council, visit your local  
council office at Caloundra, Maroochydore, Nambour or Tewantin. Or,  
if you prefer, visit us on line at www.sunshinecoast.qld.gov.au


This email, together with any attachments, is intended for the named  
recipient(s) only. Any form of review, disclosure, modification,  
distribution and or publication of this email message is prohibited  
without the express permission of the author. Please notify the  
sender immediately if you have received this email by mistake and  
delete it from your system. Unless otherwise stated, this email  
represents only the views of the sender and not the views of the  
Sunshine Coast Regional Council.

maile 3_0_0

Permission denied

[Dylan Tusler]

We've suddenly (this week) started getting "Permission denied" errors on some 
of our internal websites (page loads fine, but a little "Error on page." 
appears in the bottom left corner, and behind it is a "Permission Denied" 
error. Some functionality doesn't work, specifically it appears to be choking 
on a JavaScript POST to another page on the same site.)

Also, a number of users are reporting that they are being prompted to log in to 
web pages that previously never prompted for credentials.

One site in particular is heavily affected, and looking at the site, I can't 
see anything having changed (no web.config changes, no permissions changes, 
etc.)

I've looked at everything I can think of, including running ethereal traces and 
logging vast amounts of procmon logs. Nothing untoward appears that I can see.

Can anyone take a stab at what might be going on? I'm just getting frustrated 
with it.

Cheers

Dylan Tusler



-
To find out more about the Sunshine Coast Council, visit your local council 
office at Caloundra, Maroochydore, Nambour or Tewantin. Or, if you prefer,  
visit us on line at www.sunshinecoast.qld.gov.au

This email, together with any attachments, is intended for the named 
recipient(s) only. Any form of review, disclosure, modification, distribution 
and or publication of this email message is prohibited without the express 
permission of the author. Please notify the sender immediately if you have 
received this email by mistake and delete it from your system. Unless otherwise 
stated, this email represents only the views of the sender and not the views of 
the Sunshine Coast Regional Council.

maile 3_0_0

Re: Could not find schema information

[Jason Finch]

xsd will create a schema from your xml.
Is that what you want?   What benefit does having a schema for a config file
give you?

Mayby you want something like csd.codeplex.com ?



On Thu, May 13, 2010 at 2:06 PM, Greg Keogh  wrote:

>
> Several years ago there used to be a VS tool to create schemas from
> existing XML files. I’ll have a look and see if it’s still there somewhere.
>
>
>
> Greg
>

Could not find schema information

[Greg Keogh]

Folks, if I build a solution and have at least one error and I have an XML
file open such as a config file, then every line in the config file
generates a build Message that it "Could not find schema information". If I
fix the compile error then all of the Messages disappear.

 

I've lived with this peculiar irritation for years, but I decided it's time
to fix it.

 

Either there is a option to selectively turn the Message output off, or
perhaps it's better to include a schema. Does anyone ever create a schema
for their config files?

 

Several years ago there used to be a VS tool to create schemas from existing
XML files. I'll have a look and see if it's still there somewhere.

 

Greg

Re: Probably stupid question

[Geoff Appleby]

I can..but its fixed now :)

On Thu, May 13, 2010 at 12:33 PM, noonie  wrote:

> Geoff,
>
> How big's the project? Can you email a zip to me?
>
> --
> noonie
>
>
> On 13 May 2010 12:12, Geoff Appleby  wrote:
>
>> C# - But i'm multilingual and can translate :)
>>
>>  On Thu, May 13, 2010 at 12:09 PM, noonie  wrote:
>>
>>> VB or C# ?
>>>
>>> --
>>> noonie
>>>
>>>  On 13 May 2010 08:44, Geoff Appleby  wrote:
>>>

  Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
 always rusty...but normally I can google help. This time I just can't see
 the problem...

 I've got a repeater control that lives inside a label control. The
 repeater's itemtemplate dumps out hyperlink controls.

 The label is set to visible=false by default, and i hook the
 ItemDataBound event - if that event fires with a non-null data item, then I
 make the label visible.

 All works fine. Viewstate is enabled everywhere, and i'm rebinding all
 repeaters in every page_load.

 Most of the links over this page are just links. But I've got two
 linkbutton's that (obviously) generate a postback. When the postback fires 
 i
 _still_ rebind that repeater - and the itemdatabound event fires multiple
 times (as it should) and the hyperlink controls get recreated. i've got
 EnableViewState="true" all through those controls i've just mentioned too,
 just in case.

 But after the page renders, the repeater control is simply not there.
 the rendered html is just a   (for the wrapping label 
 control).


 I'm positive its not viewstate related (since i'm rebinding each time
 and the rebind is working - i've walked through the code and watched the
 itemdatabound event fire multiple times. but i'm totally lost.

 there's three other repeaters on the same page, and each of _those_
 still render fine.
 any thoughts?


 --
 Geoff Appleby
 Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/

>>>
>>>
>>
>>
>> --
>> Geoff Appleby
>> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>>
>
>


-- 
Geoff Appleby
Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/

Re: Probably stupid question

[Geoff Appleby]

On Thu, May 13, 2010 at 12:20 PM, Arjang Assadi wrote:

> What happened with experimenting with Repeaters?
>

Answering the language took no time at all. I was in the middle of
experimenting with repeaters at the time. I kept experimenting and got
nowhere.

Meanwhile, Silky sent me a suggestion (appears to have been directly to me,
not to the list). He said that it probably WAS viewstate getting in the road
and to explicitly turn it off. I did that - on both the label control and
the repeater control.

Shazam, the damn thing works now!!!

Thanks silky. And thanks arjang too for trying :)


>
> Why would anyone translate from the holy C# to the Barbarian VB? (
> docks and covers! )
>
> PS: Above is just a joke, no language was please, all the .net
> languages are equivalent in the eyes of CLI.
>
> Kind Regards
>
> Arjang
>
>
>
> On 13 May 2010 12:12, Geoff Appleby  wrote:
> > C# - But i'm multilingual and can translate :)
> >
> > On Thu, May 13, 2010 at 12:09 PM, noonie  wrote:
> >>
> >> VB or C# ?
> >> --
> >> noonie
> >>
> >> On 13 May 2010 08:44, Geoff Appleby  wrote:
> >>>
> >>> Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
> >>> always rusty...but normally I can google help. This time I just can't
> see
> >>> the problem...
> >>>
> >>> I've got a repeater control that lives inside a label control. The
> >>> repeater's itemtemplate dumps out hyperlink controls.
> >>>
> >>> The label is set to visible=false by default, and i hook the
> >>> ItemDataBound event - if that event fires with a non-null data item,
> then I
> >>> make the label visible.
> >>>
> >>> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
> >>> repeaters in every page_load.
> >>>
> >>> Most of the links over this page are just links. But I've got two
> >>> linkbutton's that (obviously) generate a postback. When the postback
> fires i
> >>> _still_ rebind that repeater - and the itemdatabound event fires
> multiple
> >>> times (as it should) and the hyperlink controls get recreated. i've got
> >>> EnableViewState="true" all through those controls i've just mentioned
> too,
> >>> just in case.
> >>>
> >>> But after the page renders, the repeater control is simply not there.
> the
> >>> rendered html is just a   (for the wrapping label
> control).
> >>>
> >>> I'm positive its not viewstate related (since i'm rebinding each time
> and
> >>> the rebind is working - i've walked through the code and watched the
> >>> itemdatabound event fire multiple times. but i'm totally lost.
> >>>
> >>> there's three other repeaters on the same page, and each of _those_
> still
> >>> render fine.
> >>> any thoughts?
> >>>
> >>>
> >>> --
> >>> Geoff Appleby
> >>> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
> >>
> >
> >
> >
> > --
> > Geoff Appleby
> > Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
> >
>



-- 
Geoff Appleby
Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/

Re: Probably stupid question

[noonie]

Geoff,

How big's the project? Can you email a zip to me?

-- 
noonie

On 13 May 2010 12:12, Geoff Appleby  wrote:

> C# - But i'm multilingual and can translate :)
>
> On Thu, May 13, 2010 at 12:09 PM, noonie  wrote:
>
>> VB or C# ?
>>
>> --
>> noonie
>>
>>  On 13 May 2010 08:44, Geoff Appleby  wrote:
>>
>>>
>>>  Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
>>> always rusty...but normally I can google help. This time I just can't see
>>> the problem...
>>>
>>> I've got a repeater control that lives inside a label control. The
>>> repeater's itemtemplate dumps out hyperlink controls.
>>>
>>> The label is set to visible=false by default, and i hook the
>>> ItemDataBound event - if that event fires with a non-null data item, then I
>>> make the label visible.
>>>
>>> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
>>> repeaters in every page_load.
>>>
>>> Most of the links over this page are just links. But I've got two
>>> linkbutton's that (obviously) generate a postback. When the postback fires i
>>> _still_ rebind that repeater - and the itemdatabound event fires multiple
>>> times (as it should) and the hyperlink controls get recreated. i've got
>>> EnableViewState="true" all through those controls i've just mentioned too,
>>> just in case.
>>>
>>> But after the page renders, the repeater control is simply not there. the
>>> rendered html is just a   (for the wrapping label control).
>>>
>>> I'm positive its not viewstate related (since i'm rebinding each time and
>>> the rebind is working - i've walked through the code and watched the
>>> itemdatabound event fire multiple times. but i'm totally lost.
>>>
>>> there's three other repeaters on the same page, and each of _those_ still
>>> render fine.
>>> any thoughts?
>>>
>>>
>>> --
>>> Geoff Appleby
>>> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>>>
>>
>>
>
>
> --
> Geoff Appleby
> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>

Re: Probably stupid question

[noonie]

Well thar's yer problem ;-)

On 13 May 2010 12:11, Geoff Appleby  wrote:

> C#
>
>
> On Thu, May 13, 2010 at 12:09 PM, noonie  wrote:
>
>> VB or C# ?
>>
>> --
>> noonie
>>
>>  On 13 May 2010 08:44, Geoff Appleby  wrote:
>>
>>>
>>>  Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
>>> always rusty...but normally I can google help. This time I just can't see
>>> the problem...
>>>
>>> I've got a repeater control that lives inside a label control. The
>>> repeater's itemtemplate dumps out hyperlink controls.
>>>
>>> The label is set to visible=false by default, and i hook the
>>> ItemDataBound event - if that event fires with a non-null data item, then I
>>> make the label visible.
>>>
>>> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
>>> repeaters in every page_load.
>>>
>>> Most of the links over this page are just links. But I've got two
>>> linkbutton's that (obviously) generate a postback. When the postback fires i
>>> _still_ rebind that repeater - and the itemdatabound event fires multiple
>>> times (as it should) and the hyperlink controls get recreated. i've got
>>> EnableViewState="true" all through those controls i've just mentioned too,
>>> just in case.
>>>
>>> But after the page renders, the repeater control is simply not there. the
>>> rendered html is just a   (for the wrapping label control).
>>>
>>> I'm positive its not viewstate related (since i'm rebinding each time and
>>> the rebind is working - i've walked through the code and watched the
>>> itemdatabound event fire multiple times. but i'm totally lost.
>>>
>>> there's three other repeaters on the same page, and each of _those_ still
>>> render fine.
>>> any thoughts?
>>>
>>>
>>> --
>>> Geoff Appleby
>>> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>>>
>>
>>
>
>
> --
> Geoff Appleby
> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>

Re: Probably stupid question

[Arjang Assadi]

What happened with experimenting with Repeaters?

Why would anyone translate from the holy C# to the Barbarian VB? (
docks and covers! )

PS: Above is just a joke, no language was please, all the .net
languages are equivalent in the eyes of CLI.

Kind Regards

Arjang



On 13 May 2010 12:12, Geoff Appleby  wrote:
> C# - But i'm multilingual and can translate :)
>
> On Thu, May 13, 2010 at 12:09 PM, noonie  wrote:
>>
>> VB or C# ?
>> --
>> noonie
>>
>> On 13 May 2010 08:44, Geoff Appleby  wrote:
>>>
>>> Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
>>> always rusty...but normally I can google help. This time I just can't see
>>> the problem...
>>>
>>> I've got a repeater control that lives inside a label control. The
>>> repeater's itemtemplate dumps out hyperlink controls.
>>>
>>> The label is set to visible=false by default, and i hook the
>>> ItemDataBound event - if that event fires with a non-null data item, then I
>>> make the label visible.
>>>
>>> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
>>> repeaters in every page_load.
>>>
>>> Most of the links over this page are just links. But I've got two
>>> linkbutton's that (obviously) generate a postback. When the postback fires i
>>> _still_ rebind that repeater - and the itemdatabound event fires multiple
>>> times (as it should) and the hyperlink controls get recreated. i've got
>>> EnableViewState="true" all through those controls i've just mentioned too,
>>> just in case.
>>>
>>> But after the page renders, the repeater control is simply not there. the
>>> rendered html is just a   (for the wrapping label control).
>>>
>>> I'm positive its not viewstate related (since i'm rebinding each time and
>>> the rebind is working - i've walked through the code and watched the
>>> itemdatabound event fire multiple times. but i'm totally lost.
>>>
>>> there's three other repeaters on the same page, and each of _those_ still
>>> render fine.
>>> any thoughts?
>>>
>>>
>>> --
>>> Geoff Appleby
>>> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>>
>
>
>
> --
> Geoff Appleby
> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>

Re: Probably stupid question

[Geoff Appleby]

C# - But i'm multilingual and can translate :)

On Thu, May 13, 2010 at 12:09 PM, noonie  wrote:

> VB or C# ?
>
> --
> noonie
>
>  On 13 May 2010 08:44, Geoff Appleby  wrote:
>
>>
>>  Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
>> always rusty...but normally I can google help. This time I just can't see
>> the problem...
>>
>> I've got a repeater control that lives inside a label control. The
>> repeater's itemtemplate dumps out hyperlink controls.
>>
>> The label is set to visible=false by default, and i hook the ItemDataBound
>> event - if that event fires with a non-null data item, then I make the label
>> visible.
>>
>> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
>> repeaters in every page_load.
>>
>> Most of the links over this page are just links. But I've got two
>> linkbutton's that (obviously) generate a postback. When the postback fires i
>> _still_ rebind that repeater - and the itemdatabound event fires multiple
>> times (as it should) and the hyperlink controls get recreated. i've got
>> EnableViewState="true" all through those controls i've just mentioned too,
>> just in case.
>>
>> But after the page renders, the repeater control is simply not there. the
>> rendered html is just a   (for the wrapping label control).
>>
>> I'm positive its not viewstate related (since i'm rebinding each time and
>> the rebind is working - i've walked through the code and watched the
>> itemdatabound event fire multiple times. but i'm totally lost.
>>
>> there's three other repeaters on the same page, and each of _those_ still
>> render fine.
>> any thoughts?
>>
>>
>> --
>> Geoff Appleby
>> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>>
>
>


-- 
Geoff Appleby
Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/

Re: Probably stupid question

[Geoff Appleby]

C#

On Thu, May 13, 2010 at 12:09 PM, noonie  wrote:

> VB or C# ?
>
> --
> noonie
>
>  On 13 May 2010 08:44, Geoff Appleby  wrote:
>
>>
>>  Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
>> always rusty...but normally I can google help. This time I just can't see
>> the problem...
>>
>> I've got a repeater control that lives inside a label control. The
>> repeater's itemtemplate dumps out hyperlink controls.
>>
>> The label is set to visible=false by default, and i hook the ItemDataBound
>> event - if that event fires with a non-null data item, then I make the label
>> visible.
>>
>> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
>> repeaters in every page_load.
>>
>> Most of the links over this page are just links. But I've got two
>> linkbutton's that (obviously) generate a postback. When the postback fires i
>> _still_ rebind that repeater - and the itemdatabound event fires multiple
>> times (as it should) and the hyperlink controls get recreated. i've got
>> EnableViewState="true" all through those controls i've just mentioned too,
>> just in case.
>>
>> But after the page renders, the repeater control is simply not there. the
>> rendered html is just a   (for the wrapping label control).
>>
>> I'm positive its not viewstate related (since i'm rebinding each time and
>> the rebind is working - i've walked through the code and watched the
>> itemdatabound event fire multiple times. but i'm totally lost.
>>
>> there's three other repeaters on the same page, and each of _those_ still
>> render fine.
>> any thoughts?
>>
>>
>> --
>> Geoff Appleby
>> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>>
>
>


-- 
Geoff Appleby
Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/

Re: Probably stupid question

[noonie]

VB or C# ?

-- 
noonie

On 13 May 2010 08:44, Geoff Appleby  wrote:

>
>  Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm
> always rusty...but normally I can google help. This time I just can't see
> the problem...
>
> I've got a repeater control that lives inside a label control. The
> repeater's itemtemplate dumps out hyperlink controls.
>
> The label is set to visible=false by default, and i hook the ItemDataBound
> event - if that event fires with a non-null data item, then I make the label
> visible.
>
> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
> repeaters in every page_load.
>
> Most of the links over this page are just links. But I've got two
> linkbutton's that (obviously) generate a postback. When the postback fires i
> _still_ rebind that repeater - and the itemdatabound event fires multiple
> times (as it should) and the hyperlink controls get recreated. i've got
> EnableViewState="true" all through those controls i've just mentioned too,
> just in case.
>
> But after the page renders, the repeater control is simply not there. the
> rendered html is just a   (for the wrapping label control).
>
> I'm positive its not viewstate related (since i'm rebinding each time and
> the rebind is working - i've walked through the code and watched the
> itemdatabound event fire multiple times. but i'm totally lost.
>
> there's three other repeaters on the same page, and each of _those_ still
> render fine.
> any thoughts?
>
>
> --
> Geoff Appleby
> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>

Re: Probably stupid question

[Arjang Assadi]

Hi Geoff,

There must be something different about the Repeaters that bind fine
and the one that doesn't, swap them around to see if they still bound
fine.

Is the data you expecting to bind to really the data that repeater get
binded to? Maybe the data source really has no items, I say First
Programmer Debug Thyself!

If you think it is view state related then remove the view state from
the page and see if that changes anything.

Arjang



On 13 May 2010 08:44, Geoff Appleby  wrote:
>
> Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm always
> rusty...but normally I can google help. This time I just can't see the
> problem...
>
> I've got a repeater control that lives inside a label control. The
> repeater's itemtemplate dumps out hyperlink controls.
>
> The label is set to visible=false by default, and i hook the ItemDataBound
> event - if that event fires with a non-null data item, then I make the label
> visible.
>
> All works fine. Viewstate is enabled everywhere, and i'm rebinding all
> repeaters in every page_load.
>
> Most of the links over this page are just links. But I've got two
> linkbutton's that (obviously) generate a postback. When the postback fires i
> _still_ rebind that repeater - and the itemdatabound event fires multiple
> times (as it should) and the hyperlink controls get recreated. i've got
> EnableViewState="true" all through those controls i've just mentioned too,
> just in case.
>
> But after the page renders, the repeater control is simply not there. the
> rendered html is just a   (for the wrapping label control).
>
> I'm positive its not viewstate related (since i'm rebinding each time and
> the rebind is working - i've walked through the code and watched the
> itemdatabound event fire multiple times. but i'm totally lost.
>
> there's three other repeaters on the same page, and each of _those_ still
> render fine.
> any thoughts?
>
>
> --
> Geoff Appleby
> Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/
>

Probably stupid question

[Geoff Appleby]

 Argh. This is annoying me so much. I rarely do ASP.net stuff, so I'm always
rusty...but normally I can google help. This time I just can't see the
problem...

I've got a repeater control that lives inside a label control. The
repeater's itemtemplate dumps out hyperlink controls.

The label is set to visible=false by default, and i hook the ItemDataBound
event - if that event fires with a non-null data item, then I make the label
visible.

All works fine. Viewstate is enabled everywhere, and i'm rebinding all
repeaters in every page_load.

Most of the links over this page are just links. But I've got two
linkbutton's that (obviously) generate a postback. When the postback fires i
_still_ rebind that repeater - and the itemdatabound event fires multiple
times (as it should) and the hyperlink controls get recreated. i've got
EnableViewState="true" all through those controls i've just mentioned too,
just in case.

But after the page renders, the repeater control is simply not there. the
rendered html is just a   (for the wrapping label control).

I'm positive its not viewstate related (since i'm rebinding each time and
the rebind is working - i've walked through the code and watched the
itemdatabound event fire multiple times. but i'm totally lost.

there's three other repeaters on the same page, and each of _those_ still
render fine.
any thoughts?


-- 
Geoff Appleby
Blog: http://blogs.crankygoblin.com/blogs/geoff.appleby/

RE: benefits of using vs 2010

[David Kean]

One thing that I did miss to mention, was that when I first joined Microsoft, I 
found out that Connect (or Ladybug at the time) wasn't designed to be two way 
conversation. It was designed to be an easy (which is debatable) way for 
customers to file bugs and then have them enter our (yes complex) system. There 
are approximately 30 odd product unit (with up to 3, 4 or 5 feature teams in 
each) contributing to VS/.NET - some teams handled the conversation part better 
than others, others did a terrible job.

While they have started put things in place to make sure the customer is aware 
of what's going on (I think it will no longer allows you to resolve a bug 
without adding a customer comment) - there still kinks that need to be ironed 
out.

Just more on the triage part - each feature gets to triage bugs how they like, 
this means that to the customer what appears to be one contiguous system is 
actually one abstraction over a 100 different little systems.

I'm not trying to defend this process at all - I think it used to suck really 
bad, a bunch of stuff fell though the cracks (hell I still have 9 
bugs/suggestions still open[1] from before I joined Microsoft). However, it is 
getting better - it just takes a while to get 1500 people walking in the same 
direction...

[1] 
https://connect.microsoft.com/VisualStudio/SearchResults.aspx?KeywordSearchIn=2&SearchQuery=%26quot%3bDavid+M.+Kean%26quot%3b&FeedbackType=0&Status=1&Scope=0&SortOrder=5&TabView=0

From: ozdotnet-boun...@ozdotnet.com [ozdotnet-boun...@ozdotnet.com] on behalf 
of Joseph Cooney [joseph.coo...@gmail.com]
Sent: Wednesday, May 12, 2010 4:54 AM
To: ozDotNet
Subject: Re: benefits of using vs 2010

Maybe I peppered that last comment with a little bit too much "asshole" - now 
for a response that has been marinating in the milk of human kindness.

After reading David's comments I get it - a big organization, a complex process 
with maybe everyone working in that process doing the best they can. But it 
seems in some cases (perhaps many cases) collectively the process is failing 
Microsoft, and failing the people who submit feedback, and thus I'm calling it 
broken. It's failing MS because they're disenfranchising people who could be 
(and in many cases ARE) some of their strongest supporters. Globally MS employ 
many thousands of evangelists to help people understand and use their products, 
and spend truck-loads of money on conferences, competitions, advertising and 
blogging with the end goal of building human connections with their dev 
customers around the world. If the process for submitting a bug leaves you 
feeling like you've been told to "go write a map reduce function in 
erlang" then all that evangelism 
is wasted. It's also failing MS if they miss legitimate opportunities to fix 
bugs in their product. It's failing MS customers reporting bugs because they 
feel marginalized and ignored. If this happens often enough developers will 
start thinking "I can submit a bug report on an ASP.NET problem 
I'm having, wait 6 months only to be told it's by design/won't fix/go buy some 
premier support, or I can download django or RoR and fix my own problems". It 
sounds like from what others have said and what David is describing the process 
could be improved in a number of ways

  *   Goal entry-level PSS people that triage bugs so they try harder to get a 
repro. If not having a repro greatly diminishes your chances of taking a bug 
seriously then there are going to be lots of legitimate bugs that slip through 
the cracks.
  *   Open, honest communication - if you can't fix it for the current release 
explain why. Explain what the time-frame for fixing it (or considering it if it 
is a feature suggestion) might be. There's a real catch-22 with Microsoft dev 
product cycles - external developers don't want to build serious stuff on top 
of beta1 code, but by the time beta2 rolls around it's too late to change 
things for that release, and it may be impossible to change it EVER (given the 
need for backwards computability).
  *   Accountability - if you're going to be asinine and close a bug that a 3rd 
party expert has reported to you (I'm thinking about Greg's story from earlier 
on in the thread here) and which multiple other people have commented on as 
being serious at least put your name beside it, and have some kind of channel 
where dialog about why the bug can occur.

I'm calling the process as broken - you may disagree with me, but from the 
anecdotes above, and from many others I've read around the interwebs this seems 
like a black eye in MS's engagement with developers.

Joseph

On Wed, May 12, 2010 at 9:08 PM, Arjang Assadi 
mailto:arjang.ass...@gmail.com>> wrote:
Not sure if the process is broken, it is a complex product and a
complex process.
No matter how they turn and change the process, they will not be able
to handle everything

Re: benefits of using vs 2010

[Joseph Cooney]

Maybe I peppered that last comment with a little bit too much "asshole" -
now for a response that has been marinating in the milk of human kindness.

After reading David's comments I get it - a big organization, a complex
process with maybe everyone working in that process doing the best they can.
But it seems in some cases (perhaps many cases) collectively the process is
failing Microsoft, and failing the people who submit feedback, and thus I'm
calling it broken. It's failing MS because they're disenfranchising people
who could be (and in many cases ARE) some of their strongest supporters.
Globally MS employ many thousands of evangelists to help people understand
and use their products, and spend truck-loads of money on conferences,
competitions, advertising and blogging with the end goal of building human
connections with their dev customers around the world. If the process for
submitting a bug leaves you feeling like you've been told to "go write a map
reduce function in erlang"
then all that
evangelism is wasted. It's also failing MS if they miss
legitimate opportunities to fix bugs in their product. It's failing MS
customers reporting bugs because they feel marginalized and ignored. If this
happens often enough developers will start thinking "I can submit a bug
report on an ASP.NET problem I'm having, wait 6 months only to be told it's
by design/won't fix/go buy some premier support, or I can download django or
RoR and fix my own problems". It sounds like from what others have said and
what David is describing the process could be improved in a number of ways

   - Goal entry-level PSS people that triage bugs so they try harder to get
   a repro. If not having a repro greatly diminishes your chances of taking a
   bug seriously then there are going to be lots of legitimate bugs that slip
   through the cracks.
   - Open, honest communication - if you can't fix it for the current
   release explain why. Explain what the time-frame for fixing it (or
   considering it if it is a feature suggestion) might be. There's a real
   catch-22 with Microsoft dev product cycles - external developers don't want
   to build serious stuff on top of beta1 code, but by the time beta2 rolls
   around it's too late to change things for that release, and it may be
   impossible to change it EVER (given the need for backwards computability).
   - Accountability - if you're going to be asinine and close a bug that a
   3rd party expert has reported to you (I'm thinking about Greg's story from
   earlier on in the thread here) and which multiple other people have
   commented on as being serious at least put your name beside it, and have
   some kind of channel where dialog about why the bug can occur.


I'm calling the process as broken - you may disagree with me, but from the
anecdotes above, and from many others I've read around the interwebs this
seems like a black eye in MS's engagement with developers.

Joseph

On Wed, May 12, 2010 at 9:08 PM, Arjang Assadi wrote:

> Not sure if the process is broken, it is a complex product and a
> complex process.
> No matter how they turn and change the process, they will not be able
> to handle everything,
> That is not an excuse but just an intrinsic property of complex systems.
>
> Kind Regards
>
> Arjang Assadi
>
> On 12 May 2010 21:02, Joseph Cooney  wrote:
> > With all due respect, explaining a broken process doesn't make it any
> less
> > broken.
> >
> > On Wed, May 12, 2010 at 6:44 PM, David Kean 
> > wrote:
> >>
> >> Alright, given that I've actually been on both sides of the fences on
> this
> >> one, let me try and explain what happens on the other side:
> >>
> >> 1) Customer files a bug on Connect, it appears in our TFS bug database
> >> internally.
> >> 2) First CSS/PSS or whatever they are called these days have a look at
> >> it to try and reproduce the problem. This is to reduce the amount of
> product
> >> support that the feature team themselves have to do (which would take us
> >> away from feature work).
> >> 3) As these are support personnal and did not actually work on the
> >> product, they usually don't have as much context as the feature team
> >> themselves - hence why some bugs that seem obvious to someone who's used
> the
> >> technology extensively might be resolved as not-reproducible. The best
> way
> >> to get through CSS is to produce a simple repro project that clearly
> shows
> >> the bug.
> >> 4) After CSS have reproduced the problem (or if it is a suggestion),
> they
> >> assign the bug to the feature triage team (usually a senior PM, dev and
> >> test) to look at it. CSS also will add a comment to the customer to tell
> >> them that they have done that.
> >> 5) We look at the bug to determine a couple of things:
> >>
> >> i) Is it by-design? The bug may be exhibiting behavior called out in the
> >> documentation, or called out in the spec (internal document describing
> the
> >> design of the featu

Re: benefits of using vs 2010

[David Burstin]

On Wed, May 12, 2010 at 9:27 PM, Craig van Nieuwkerk wrote:

> > With all due respect, explaining a broken process doesn't make it any
> less
> > broken.
> >
>
> I didn't read anything that lead me to believe the process is broken.
> A number of fair reasons were given why a bug might not be fixed.
>
> 1. Can't be reproduced
> 2. Not really a bug
> 3. Will have significant backwards compatibility issues
> 4. Not part of the product that is a priority going forward
> 5. Extreme edge case
>
> You may disagree with their decision, especially when you are not
> privy to the reasoning behind it, but to think they just dismiss user
> reported bugs is a bit ridiculous.
>
>
Agreed. the parts you mention are not broken. Some of the parts you don't
mention are:

1."Won't fix" might mean will never fix, might almost mean "postponed" - no
way to tell the difference.
2. Can't tell if bugs are user generated so replies often not sent.
3. Database upgrades lose information.

I would suggest these parts are broken.

And in the spirit of a post from a while back:
*+1. I agree with everything I just said.*

Cheers
Dave

Craig,
>

Re: benefits of using vs 2010

[Craig van Nieuwkerk]

> With all due respect, explaining a broken process doesn't make it any less
> broken.
>

I didn't read anything that lead me to believe the process is broken.
A number of fair reasons were given why a bug might not be fixed.

1. Can't be reproduced
2. Not really a bug
3. Will have significant backwards compatibility issues
4. Not part of the product that is a priority going forward
5. Extreme edge case

You may disagree with their decision, especially when you are not
privy to the reasoning behind it, but to think they just dismiss user
reported bugs is a bit ridiculous.

Craig,

Re: benefits of using vs 2010

[silky]

On Wed, May 12, 2010 at 9:08 PM, Arjang Assadi  wrote:
> Not sure if the process is broken, it is a complex product and a
> complex process.
> No matter how they turn and change the process, they will not be able
> to handle everything,
> That is not an excuse but just an intrinsic property of complex systems.

No, it *is* an excuse and it is *not* an intrinsic property of
"complex systems".

Your comment makes no sense.

The *world* is a complex system; things can be "handled" by breaking
everything done into smaller managable parts and doing things one by
one.

This is the very essense of getting *anything* done.


> Kind Regards
>
> Arjang Assadi

-- 
silky

  http://www.programmingbranch.com/

Re: benefits of using vs 2010

[Arjang Assadi]

Not sure if the process is broken, it is a complex product and a
complex process.
No matter how they turn and change the process, they will not be able
to handle everything,
That is not an excuse but just an intrinsic property of complex systems.

Kind Regards

Arjang Assadi

On 12 May 2010 21:02, Joseph Cooney  wrote:
> With all due respect, explaining a broken process doesn't make it any less
> broken.
>
> On Wed, May 12, 2010 at 6:44 PM, David Kean 
> wrote:
>>
>> Alright, given that I've actually been on both sides of the fences on this
>> one, let me try and explain what happens on the other side:
>>
>> 1) Customer files a bug on Connect, it appears in our TFS bug database
>> internally.
>> 2) First CSS/PSS or whatever they are called these days have a look at
>> it to try and reproduce the problem. This is to reduce the amount of product
>> support that the feature team themselves have to do (which would take us
>> away from feature work).
>> 3) As these are support personnal and did not actually work on the
>> product, they usually don't have as much context as the feature team
>> themselves - hence why some bugs that seem obvious to someone who's used the
>> technology extensively might be resolved as not-reproducible. The best way
>> to get through CSS is to produce a simple repro project that clearly shows
>> the bug.
>> 4) After CSS have reproduced the problem (or if it is a suggestion), they
>> assign the bug to the feature triage team (usually a senior PM, dev and
>> test) to look at it. CSS also will add a comment to the customer to tell
>> them that they have done that.
>> 5) We look at the bug to determine a couple of things:
>>
>> i) Is it by-design? The bug may be exhibiting behavior called out in the
>> documentation, or called out in the spec (internal document describing the
>> design of the feature). Or it may be relying on behavior that we don't
>> guarantee (such as relying on the result of String.GetHashCode).
>> ii) Is it really a suggestion? Is the request a new feature, API or
>> behavior that we previously didn't have? These usually fall in priority
>> against normal bugs - and we usually consider these in the next planning
>> milestones (which in the 6 months to a year of the product cycle means next
>> version).
>> iii) Is it a bug that we would fix? A variety of factors come into play
>> when we decide whether we should fix the bug; How risky is it? Would it
>> break compatibility? How many customers would benefit from it? It is a
>> corner case? Does it have a reasonable workaround? Is it in an area that
>> we're no longer investing in?
>>
>> The ultimate resolution of a bug can take many months depending on the
>> which part of the product cycle we are in, bouncing among various members on
>> the team to gather information, and then usually sent back to the triage
>> team to decide above. The triage team will then usually add a comment to the
>> customer.
>>
>> Now the tricky part of above, is that you guys don't see the whole story
>> behind the bug. While a bug may have one or two public comments from
>> Microsoft, internally there are usually a whole bunch of comments from devs,
>> PMs and QA explaining the underlying details, calling out the spec or doc
>> that describes the behavior, or explains how it would break compatibility.
>> Unfortunately, due to the design of the system - it's very easy to forget to
>> add comment to the customer to explain what's occurring underneath or to
>> even know that the bug itself is a customer filed bug. This is why sometimes
>> bugs are closed without comments.
>>
>> On top of this, we actually change backend databases every product
>> version, and when this happens sometimes the link between the external site
>> and the internal database breaks, meaning that any updates to the bug are
>> not shown externally. If you've got any bugs from 2005 that are still
>> active, then chances are this is one of these cases. I've re-raised this
>> issue a couple of weeks ago, so hopefully we can a resolution soon for
>> these.
>>
>> Another thing that I should add about the 'Won't Fix' tag: This can
>> actually have two meanings depending on the team:
>>
>> 1) It really means Won't Fix - something that the team won't look at
>> fixing unless a lot of people hit the same bug or provide feedback.
>> 2) It means Won't Fix for this release, but we'll add a special tag to it
>> that means 'consider it in the planning for vNext' - this is similar, but
>> confusingly not the same, to the Postponed resolution.
>>
>> Unfortunately, external customers can't see which one this is. You need to
>> gleam this from the comments of the product team.
>>
>> Now this turned out to be longer than I'd planned, its late over here
>> (1:41am) and I really should go to bed.
>>
>> 
>> From: ozdotnet-boun...@ozdotnet.com [ozdotnet-boun...@ozdotnet.com] on
>> behalf of Eddie de Bear [eddie.deb...@gmail.com]
>> Sent: Tuesday, May 11, 2010 10

Re: benefits of using vs 2010

[Joseph Cooney]

With all due respect, explaining a broken process doesn't make it any less
broken.

On Wed, May 12, 2010 at 6:44 PM, David Kean wrote:

>  Alright, given that I've actually been on both sides of the fences on
> this one, let me try and explain what happens on the other side:
>
> 1) Customer files a bug on Connect, it appears in our TFS bug database
> internally.
> 2) First CSS/PSS or whatever they are called these days have a look at
> it to try and reproduce the problem. This is to reduce the amount of product
> support that the feature team themselves have to do (which would take us
> away from feature work).
> 3) As these are support personnal and did not actually work on the product,
> they usually don't have as much context as the feature team themselves -
> hence why some bugs that seem obvious to someone who's used the technology
> extensively might be resolved as not-reproducible. The best way to get
> through CSS is to produce a simple repro project that clearly shows the bug.
> 4) After CSS have reproduced the problem (or if it is a suggestion), they
> assign the bug to the feature triage team (usually a senior PM, dev and
> test) to look at it. CSS also will add a comment to the customer to tell
> them that they have done that.
> 5) We look at the bug to determine a couple of things:
>
> i) Is it by-design? The bug may be exhibiting behavior called out in the
> documentation, or called out in the spec (internal document describing the
> design of the feature). Or it may be relying on behavior that we don't
> guarantee (such as relying on the result of String.GetHashCode).
> ii) Is it really a suggestion? Is the request a new feature, API or
> behavior that we previously didn't have? These usually fall in priority
> against normal bugs - and we usually consider these in the next planning
> milestones (which in the 6 months to a year of the product cycle means next
> version).
> iii) Is it a bug that we would fix? A variety of factors come into play
> when we decide whether we should fix the bug; How risky is it? Would it
> break compatibility? How many customers would benefit from it? It is a
> corner case? Does it have a reasonable workaround? Is it in an area that
> we're no longer investing in?
>
> The ultimate resolution of a bug can take many months depending on the
> which part of the product cycle we are in, bouncing among various members on
> the team to gather information, and then usually sent back to the triage
> team to decide above. The triage team will then usually add a comment to the
> customer.
>
> Now the tricky part of above, is that you guys don't see the whole story
> behind the bug. While a bug may have one or two public comments from
> Microsoft, internally there are usually a whole bunch of comments from devs,
> PMs and QA explaining the underlying details, calling out the spec or doc
> that describes the behavior, or explains how it would break compatibility.
> Unfortunately, due to the design of the system - it's very easy to forget to
> add comment to the customer to explain what's occurring underneath or to
> even know that the bug itself is a customer filed bug. This is why sometimes
> bugs are closed without comments.
>
> On top of this, we actually change backend databases every product version,
> and when this happens sometimes the link between the external site and the
> internal database breaks, meaning that any updates to the bug are not shown
> externally. If you've got any bugs from 2005 that are still active, then
> chances are this is one of these cases. I've re-raised this issue a couple
> of weeks ago, so hopefully we can a resolution soon for these.
>
> Another thing that I should add about the 'Won't Fix' tag: This can
> actually have two meanings depending on the team:
>
> 1) It really means Won't Fix - something that the team won't look at fixing
> unless a lot of people hit the same bug or provide feedback.
> 2) It means Won't Fix for this release, but we'll add a special tag to it
> that means 'consider it in the planning for vNext' - this is similar, but
> confusingly not the same, to the Postponed resolution.
>
> Unfortunately, external customers can't see which one this is. You need to
> gleam this from the comments of the product team.
>
> Now this turned out to be longer than I'd planned, its late over here
> (1:41am) and I really should go to bed.
>
>  --
> *From:* ozdotnet-boun...@ozdotnet.com [ozdotnet-boun...@ozdotnet.com] on
> behalf of Eddie de Bear [eddie.deb...@gmail.com]
> *Sent:* Tuesday, May 11, 2010 10:05 PM
> *To:* g...@greglow.com; ozDotNet
>
> *Subject:* Re: benefits of using vs 2010
>
>   I agree with Greg on this one. I've submitted bugs and enhancements
> which received positive responses (from Microsoft) only to be closed "Won't
> Fix" at the last minute. Even if they were migrated to VS-Next would have
> been a better option, but to have them closed with no explanation just
> discourages people fro

Re; [OT] Odd Question/Situation

[silky]

> Got eye exam, got reading gleasses, But when there is zoom do we need 
> gleasses?
>
> If we can change the size of what we read do we really need to use
> reading glasses (and keep the font the same size)? It just doesn't
> make sense , guess this is a question for Dr Carl!

Assuming you have either Hyperopia (Far-sighted) or Myopia
(Short-sighted), the answer would appear to be yes - you still need
glasses (in agreement with others).

>From your description I'm assuming you have Hyperopia. This means that
something has to be far away to be in focus.

The reason for the issue, if I may, is that the eyeball is too short.
This means that the focal point of the eye is actually *behind* the
retina.

So what you've got is some glasses that correct this, by creating a
'virtual' image (of the close object) at slightly further distance
that you can actually focus at. So some lenses are created for you in
the following fashion:

1/[normal near focal point: 25cm] + 1/[your actual focal point] =
1/[focal length]

The final answer being something like: P = 3.3D (this might be on your
presciption; you'll need to calculate the numbers yourself).

Anyway, what I should probably have said, is that the size of the
object has no bearing on whether it is in focus. For it to be in
focus, the previous equation, called the "lense-makers" equation[1]:

1/[object distance] + 1/[image distance] = 1/[focal length]

Must be satisfied. The eye can change its own focal length, so all the
matters are the distances. Just because you make something larger
doesn't mean its closer.

Now, let it be said, I may have absolutely no idea what I'm talking about.


> I know it is not Friday
>
> Regards
>
> Arjang

-- 
silky

  http://www.programmingbranch.com/

[1]: http://en.wikipedia.org/wiki/Lens_%28optics%29

RE: benefits of using vs 2010

[David Kean]

Alright, given that I've actually been on both sides of the fences on this one, 
let me try and explain what happens on the other side:

1) Customer files a bug on Connect, it appears in our TFS bug database 
internally.
2) First CSS/PSS or whatever they are called these days have a look at it to 
try and reproduce the problem. This is to reduce the amount of product support 
that the feature team themselves have to do (which would take us away from 
feature work).
3) As these are support personnal and did not actually work on the product, 
they usually don't have as much context as the feature team themselves - hence 
why some bugs that seem obvious to someone who's used the technology 
extensively might be resolved as not-reproducible. The best way to get through 
CSS is to produce a simple repro project that clearly shows the bug.
4) After CSS have reproduced the problem (or if it is a suggestion), they 
assign the bug to the feature triage team (usually a senior PM, dev and test) 
to look at it. CSS also will add a comment to the customer to tell them that 
they have done that.
5) We look at the bug to determine a couple of things:

i) Is it by-design? The bug may be exhibiting behavior called out in the 
documentation, or called out in the spec (internal document describing the 
design of the feature). Or it may be relying on behavior that we don't 
guarantee (such as relying on the result of String.GetHashCode).
ii) Is it really a suggestion? Is the request a new feature, API or behavior 
that we previously didn't have? These usually fall in priority against normal 
bugs - and we usually consider these in the next planning milestones (which in 
the 6 months to a year of the product cycle means next version).
iii) Is it a bug that we would fix? A variety of factors come into play when we 
decide whether we should fix the bug; How risky is it? Would it break 
compatibility? How many customers would benefit from it? It is a corner case? 
Does it have a reasonable workaround? Is it in an area that we're no longer 
investing in?

The ultimate resolution of a bug can take many months depending on the which 
part of the product cycle we are in, bouncing among various members on the team 
to gather information, and then usually sent back to the triage team to decide 
above. The triage team will then usually add a comment to the customer.

Now the tricky part of above, is that you guys don't see the whole story behind 
the bug. While a bug may have one or two public comments from Microsoft, 
internally there are usually a whole bunch of comments from devs, PMs and QA 
explaining the underlying details, calling out the spec or doc that describes 
the behavior, or explains how it would break compatibility. Unfortunately, due 
to the design of the system - it's very easy to forget to add comment to the 
customer to explain what's occurring underneath or to even know that the bug 
itself is a customer filed bug. This is why sometimes bugs are closed without 
comments.

On top of this, we actually change backend databases every product version, and 
when this happens sometimes the link between the external site and the internal 
database breaks, meaning that any updates to the bug are not shown externally. 
If you've got any bugs from 2005 that are still active, then chances are this 
is one of these cases. I've re-raised this issue a couple of weeks ago, so 
hopefully we can a resolution soon for these.

Another thing that I should add about the 'Won't Fix' tag: This can actually 
have two meanings depending on the team:

1) It really means Won't Fix - something that the team won't look at fixing 
unless a lot of people hit the same bug or provide feedback.
2) It means Won't Fix for this release, but we'll add a special tag to it that 
means 'consider it in the planning for vNext' - this is similar, but 
confusingly not the same, to the Postponed resolution.

Unfortunately, external customers can't see which one this is. You need to 
gleam this from the comments of the product team.

Now this turned out to be longer than I'd planned, its late over here (1:41am) 
and I really should go to bed.


From: ozdotnet-boun...@ozdotnet.com [ozdotnet-boun...@ozdotnet.com] on behalf 
of Eddie de Bear [eddie.deb...@gmail.com]
Sent: Tuesday, May 11, 2010 10:05 PM
To: g...@greglow.com; ozDotNet
Subject: Re: benefits of using vs 2010

I agree with Greg on this one. I've submitted bugs and enhancements which 
received positive responses (from Microsoft) only to be closed "Won't Fix" at 
the last minute. Even if they were migrated to VS-Next would have been a better 
option, but to have them closed with no explanation just discourages people 
from submitting anything.

Ed.

On Wed, May 12, 2010 at 2:04 PM, Greg Low (greglow.com) 
mailto:g...@greglow.com>> wrote:
Too true Mitch.

Unfortunately, most of the folk I know that used to submit a lot of bugs and 
suggestions have stopped

Re: [OT] Odd Question/Situation

[Stephen Price]

I drew a cartoon once of a guy rocking up to surgery to have a colonoscopy,
with a box of popcorn in hand. Can't believe they let you watch that. No,
that wasn't from experience, my dad gave me the idea for the joke.

http://www.motivatedphotos.com/?id=16965 Some things can not be unseen.

On Wed, May 12, 2010 at 3:21 PM, Michael Minutillo <
michael.minuti...@gmail.com> wrote:

> I'm fine with all of that except the bit where you're awake watching them
> do it. I don't care how much Valium or how many anesthetic eye drops I'm
> given I'm not doing that.
>
>
> On Wed, May 12, 2010 at 3:12 PM, David Connors  wrote:
>
>> On 12 May 2010 17:04, Stephen Price  wrote:
>>
>>> Hmm... write/run a cool application or have my cornea's gouged out with
>>> laser beams. Tough choice...
>>
>>
>> I watched a bunch of youtube videos before my wife had Lasik ... I don't
>> think they can really use any Lasik footage ever when trying to sell the
>> operation at $2500 per eye.
>>
>> They peel your eyelids back with little clips and then put a mechanical
>> clamp thing on your eyeball itself. Then they slice the top off your eyeball
>> with a very, very, very small microtome. Then they vapourise the exposed bit
>> of your eye with the Eye Laser (you have to say it like Dr Evil) before
>> putting the flap they microtomed off back over (that helps it heal faster
>> apparently).
>>
>> I think I just talked 300 people out of Lasik.
>>
>> --
>> David Connors (da...@codify.com)
>> Software Engineer
>> Codify Pty Ltd - www.codify.com
>> Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
>> 189 363
>> V-Card: https://www.codify.com/cards/davidconnors
>> Address Info: https://www.codify.com/contact
>>
>>
>
>
> --
> Michael M. Minutillo
> Indiscriminate Information Sponge
> Blog: http://wolfbyte-net.blogspot.com
>

Re: [OT] Odd Question/Situation

[David Burstin]

On Wed, May 12, 2010 at 5:21 PM, Michael Minutillo <
michael.minuti...@gmail.com> wrote:

> I'm fine with all of that except the bit where you're awake watching them
> do it. I don't care how much Valium or how many anesthetic eye drops I'm
> given I'm not doing that.
>
> My wife has a degenerative eye disease and recently had to get cataract
surgery. They peel away the skin over the lens, then remove the lens and
replace it with a plastic one before re-covering it. All of this while awake
and watching (until your eye goes blurry when the lens is removed).

I'll take Lasik any day over this.


>
> --
> Michael M. Minutillo
> Indiscriminate Information Sponge
> Blog: http://wolfbyte-net.blogspot.com
>

Re: [OT] Odd Question/Situation

[Michael Minutillo]

I'm fine with all of that except the bit where you're awake watching them do
it. I don't care how much Valium or how many anesthetic eye drops I'm given
I'm not doing that.

On Wed, May 12, 2010 at 3:12 PM, David Connors  wrote:

> On 12 May 2010 17:04, Stephen Price  wrote:
>
>> Hmm... write/run a cool application or have my cornea's gouged out with
>> laser beams. Tough choice...
>
>
> I watched a bunch of youtube videos before my wife had Lasik ... I don't
> think they can really use any Lasik footage ever when trying to sell the
> operation at $2500 per eye.
>
> They peel your eyelids back with little clips and then put a mechanical
> clamp thing on your eyeball itself. Then they slice the top off your eyeball
> with a very, very, very small microtome. Then they vapourise the exposed bit
> of your eye with the Eye Laser (you have to say it like Dr Evil) before
> putting the flap they microtomed off back over (that helps it heal faster
> apparently).
>
> I think I just talked 300 people out of Lasik.
>
> --
> David Connors (da...@codify.com)
> Software Engineer
> Codify Pty Ltd - www.codify.com
> Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
> 189 363
> V-Card: https://www.codify.com/cards/davidconnors
> Address Info: https://www.codify.com/contact
>
>


-- 
Michael M. Minutillo
Indiscriminate Information Sponge
Blog: http://wolfbyte-net.blogspot.com

Re: [OT] Odd Question/Situation

[David Connors]

On 12 May 2010 17:04, Stephen Price  wrote:

> Hmm... write/run a cool application or have my cornea's gouged out with
> laser beams. Tough choice...


I watched a bunch of youtube videos before my wife had Lasik ... I don't
think they can really use any Lasik footage ever when trying to sell the
operation at $2500 per eye.

They peel your eyelids back with little clips and then put a mechanical
clamp thing on your eyeball itself. Then they slice the top off your eyeball
with a very, very, very small microtome. Then they vapourise the exposed bit
of your eye with the Eye Laser (you have to say it like Dr Evil) before
putting the flap they microtomed off back over (that helps it heal faster
apparently).

I think I just talked 300 people out of Lasik.

-- 
David Connors (da...@codify.com)
Software Engineer
Codify Pty Ltd - www.codify.com
Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
189 363
V-Card: https://www.codify.com/cards/davidconnors
Address Info: https://www.codify.com/contact

RE: [OT] Odd Question/Situation

[David Boccabella]

Working in an optical lens grinding company there are many ways to grind
lenses to suit programmers.  One of the main ones we do is call Autograph
Office for that purpose.

 

When grinding we not only take into account the direct vision i.e. - what
the eye is looking at when looking ahead, but also when the eye needs to
move side to side as in reading or looking at a computer screen.

 

For example - with the glasses I am wearing now - the centre of the screen
is in focus, and the edges of the screen are also in focus and not
distorted.

 

With non Office lenses you will find that the centre of the screen is
perfect however the edges are blurred until you move your head to read the
edges (by directing your vision). You cannot move your eyes because you will
be looking at the lens through an angle.

 

The same with the up/down vision as the lower section of the lens is ground
to give better results when looking slightly down at a screen, and when you
look up the upper part of the lens is ground for longer vision.

 

So hopefully that will help.

 

Dave

 

 


David J. Boccabella

Proprietor
Anubis Systems
Phone: 0433 808 525

Fax: 3200 0085
Email:    davidboccabe...@anubis-systems.com



This e-mail and it's contents is confidential to Anubis Systems.
This e-mail, any attachments, or any part of can not be reproduced
without the express written permission of Anubis Systems


 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Stephen Price
Sent: Wednesday, 12 May 2010 4:55 PM
To: ozDotNet
Subject: Re: [OT] Odd Question/Situation

 

I had this cool idea of applying a distortion or blur over the top of your
monitor so that it corrects for astigmatism. It would mean you could sit and
look at your screen all day without needing to use glasses, and without
getting tired eyes. 

 

The thing with astigmatism is that you have different focal lengths for
vertical vs horizontal lines. Text is made up of both vertical and
horizontal lines so your eyes continually refocusing (when I was younger my
eyes could do it for a long time before getting exhausted so I didn't know I
had it until I got older and started getting blurry vision after reading for
half hour). It would be so cool to turn on an app and take off your glasses.
:)

On Wed, May 12, 2010 at 2:42 PM, mike smith  wrote:

On 12 May 2010 15:04, Arjang Assadi  wrote:
> Got eye exam, got reading gleasses, But when there is zoom do we need
gleasses?
>
> If we can change the size of what we read do we really need to use
> reading glasses (and keep the font the same size)? It just doesn't
> make sense , guess this is a question for Dr Carl!

Glasses don't just fix magnification, they fix things like astigmatism

http://en.wikipedia.org/wiki/Astigmatism_(eye)

And probably other stuff - that's a lot of what my long distance
glasses are fixing though.


>
> I know it is not Friday

It must be Thursday, I never could get the hang of Thursdays.


>
> Regards
>
> Arjang
>



--
Meski

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

 

Re: [OT] Odd Question/Situation

[Stephen Price]

Hmm... write/run a cool application or have my cornea's gouged out with
laser beams. Tough choice...

On Wed, May 12, 2010 at 3:00 PM, David Connors  wrote:

> On 12 May 2010 16:54, Stephen Price  wrote:
>
>> I had this cool idea of applying a distortion or blur over the top of your
>> monitor so that it corrects for astigmatism. It would mean you could sit and
>> look at your screen all day without needing to use glasses, and without
>> getting tired eyes.
>>
>> The thing with astigmatism is that you have different focal lengths for
>> vertical vs horizontal lines. Text is made up of both vertical and
>> horizontal lines so your eyes continually refocusing (when I was younger my
>> eyes could do it for a long time before getting exhausted so I didn't know I
>> had it until I got older and started getting blurry vision after reading for
>> half hour). It would be so cool to turn on an app and take off your glasses.
>> :)
>>
>
> Or get Lasik (works in RL too - not just on the Internet).
>
> --
> David Connors (da...@codify.com)
> Software Engineer
> Codify Pty Ltd - www.codify.com
> Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
> 189 363
> V-Card: https://www.codify.com/cards/davidconnors
> Address Info: https://www.codify.com/contact
>
>

Re: [OT] Odd Question/Situation

[David Connors]

On 12 May 2010 16:54, Stephen Price  wrote:

> I had this cool idea of applying a distortion or blur over the top of your
> monitor so that it corrects for astigmatism. It would mean you could sit and
> look at your screen all day without needing to use glasses, and without
> getting tired eyes.
>
> The thing with astigmatism is that you have different focal lengths for
> vertical vs horizontal lines. Text is made up of both vertical and
> horizontal lines so your eyes continually refocusing (when I was younger my
> eyes could do it for a long time before getting exhausted so I didn't know I
> had it until I got older and started getting blurry vision after reading for
> half hour). It would be so cool to turn on an app and take off your glasses.
> :)
>

Or get Lasik (works in RL too - not just on the Internet).

-- 
David Connors (da...@codify.com)
Software Engineer
Codify Pty Ltd - www.codify.com
Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
189 363
V-Card: https://www.codify.com/cards/davidconnors
Address Info: https://www.codify.com/contact