Jobs

17 new messages in 11 topics - digest


== 1 of 1 ==
Date: Fri, May 9 2008 1:32 pm
From: Jon Skeet [C# MVP]


Jon Skeet [C# MVP] <skeet@pobox.com> wrote:

<snip>

> Another one to ask the team, I guess...

Here's the reply:

<quote>
This certainly looks like an error in the specification. I'll see what
we can do about getting it fixed.  Thanks for bringing it to our
attention.
</quote>

--
Jon Skeet - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com





==============================================================================
TOPIC: Stop XmlDocument.Load() from using cached data?
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/6f3892acd2eca71b?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, May 9 2008 1:36 pm
From: Mahmoud Al-Qudsi


Is there any way to stop an XmlDocument object from using data grabbed
from a previous request?

e.g. if I used XmlDocument.Load to grab a URI, and I know that this
URI changes often (for example, an RSS feed) can I somehow tell the
framework to not use cached data?

Will I have to create a custom HttpWebRequest and convert the data to
an XmlDocument for processing or is there some way to tell XmlDocument
(perhaps via the XmlResolver somehow?) to never use the cache?

Thanks.




== 2 of 3 ==
Date: Fri, May 9 2008 3:09 pm
From: "Anthony Jones"



"Mahmoud Al-Qudsi" <mqudsi@gmail.com> wrote in message
news:e1118045-cc1f-4768-a47e-5753f912b452@y21g2000hsf.googlegroups.com...
> Is there any way to stop an XmlDocument object from using data grabbed
> from a previous request?
>
> e.g. if I used XmlDocument.Load to grab a URI, and I know that this
> URI changes often (for example, an RSS feed) can I somehow tell the
> framework to not use cached data?
>
> Will I have to create a custom HttpWebRequest and convert the data to
> an XmlDocument for processing or is there some way to tell XmlDocument
> (perhaps via the XmlResolver somehow?) to never use the cache?
>

The Load method honors the WebRequest Caching policy which by default is set
to bypass the cache.  However its worth noting that this actually means
bypass the local cache it does not add a pragma: no-cache header to the
request and therefore other caches such as a proxy server between the client
and the origin server may serve content from a cache.

You will need to use HttpWebRequest if the default behaviour (or your
prevailing settings set via the requestCaching element in the .config(s)) is
not want you need.

I suggest you use a policy created wth Revalidate level.


--
Anthony Jones - MVP ASP/ASP.NET






== 3 of 3 ==
Date: Fri, May 9 2008 3:19 pm
From: Mahmoud Al-Qudsi



> You will need to use HttpWebRequest if the default behaviour (or your
> prevailing settings set via the requestCaching element in the .config(s)) is
> not want you need.
>
> I suggest you use a policy created wth Revalidate level.

I take it this will this do the trick then?

....
WebRequest.DefaultCachePolicy = new
RequestCachePolicy(RequestCacheLevel.Revalidate);
XmlDocument xmlDocument = new XmlDocument();
xmlDocument.Load(myUri);





==============================================================================
TOPIC: Compiler Error CS0702
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/d05837464d358b50?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, May 9 2008 1:33 pm
From: Jon Skeet [C# MVP]


Jon Skeet [C# MVP] <skeet@pobox.com> wrote:

<snip>

> > I don't see a conceptual reason why "where T : enum" _shouldn't_ be supported.
>
> Likewise. I don't think any of us have come up with a reason why it
> shouldn't be supported. I'd be interested to know the reason too - but
> I don't think you'll find it here ;)

I asked the C# team about this issue, and got this reply:

<quote>
First off, your conjecture is correct; the restrictions on constraints
are by and large artefacts of the language, not so much the CLR. (Were
we to do these features there would be a few minor things we=3Fd like to
change in the CLR regarding how enumerable types are specified, but
mostly this would be language work.)

Second, I would personally love to have delegate constraints, enum
constraints, and the ability to specify constraints that are illegal
today because the compiler is trying to save you from yourself. (That
is, making sealed types legal as constraints, and so on.)

However, due to scheduling restrictions, we will likely not be able to
get these features into the next version of the language.
</quote>

--
Jon Skeet - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com




== 2 of 2 ==
Date: Fri, May 9 2008 2:13 pm
From: PIEBALD


> However, due to scheduling restrictions, we will likely not be able to

That's what I thought. I'll keep my fingers crossed. Thanks for your effort.





==============================================================================
TOPIC: SaveFileDialog Changing Environment.CurrentDirectory
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/331d06b8a54a4d5a?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, May 9 2008 1:42 pm
From: "Peter Duniho"


On Fri, 09 May 2008 12:45:02 -0700, jehugaleahsa@gmail.com
<jehugaleahsa@gmail.com> wrote:

> Hello:
>
> Correct me if I'm wrong, but it appears that saving a file with the
> SaveFileDialog changes the Environment.CurrentDirectory property.
>
> How can I prevent this?

This has been answered before:
http://groups.google.com/groups/search?q=group%3Amicrosoft.public.dotnet.languages.csharp+file+dialog+current+directory&qt_s=Search

In some of the top threads related to that search, you'll find mention
that the FileDialog.RestoreDirectory property controls this behavior.

Of course, I suppose you could have also just looked at the documentation
for the SaveFileDialog.  IMHO, the first thing anyone should do when they
are trying to find the answer to a question related to the use of a
particular framework class is read through the entire list of public
members of the class in question.  Often what you're looking for will be
found there.  :)

If you look through the previous threads that Google shows you, you will
also see good advice that generally you should not be relying on the
current directory anyway.  Sometimes when dealing with legacy code it's
safer to just not change the current directory.  But it's usually better
to just use full path names when referencing the file system.  Then you're
not dependent on side-effects of other code and/or use actions.

Pete





==============================================================================
TOPIC: Threads and Exceptions
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/d39df2bc2eacbcf4?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, May 9 2008 2:02 pm
From: "Peter Duniho"


On Fri, 09 May 2008 13:28:13 -0700, DaveC <davecove@gmail.com> wrote:

> Based on what Peter B referred me to I got my problem solved. Time to
> share the solution.

All due respect to the other Peter, I don't see that as a very good
solution.

The basic problem is that you never solve the problem of the call to
ReadResponse() completing.  In particular, if that call really is going to
block indefinitely, you have now completely tied up a thread pool thread
for the remaining lifetime of your program.  Do this too often, and you
will eventually consume your entire thread pool.

It's unfortunate that Peter B's article does not mention this serious flaw
at all.  His test code may not ever exhibit the problem, because he
changed the API to eventually complete (i.e. he passes in a
"secondsToWait", which implies to me that his test code probably just
sleeps for some number of seconds before returning).  But in a real world
application, where the method may not ever actually complete, it's a
problem.

There are also minor problems with the implementation you posted.  Two
obvious ones are:

> [...]
>         private delegate string del_StreamReader(ref SshStream ssh); //
> declare a delegate to use in the timeout

There is no need for the parameter to be defined as "ref".  You aren't
changing the value of the parameter, so passing by reference is
superfluous.  You seem to have added this problem all by yourself.

Also:

> [...]
>             IAsyncResult sync_result = del_sr.BeginInvoke(ref ssh,
> null, new object());    //Invoke the delegate and pass parameters

You are passing "null" for the async callback parameter to BeginInvoke(),
so the third parameter -- the value passed to the callback -- is
superfluous.  This problem seems to have been inherited from Peter B's
article.

Even if you did have a callback, passing a plain instance of Object would
almost always be pointless.  The reason that parameter exists is to
provide the callback with some context for its processing.  Since an
instance of Object has no context that's useful for most purposes, passing
one as the context doesn't make sense.  (The one exception I can think of
would be using it for synchronization purposes -- i.e. using it for a
lock() or in a call to a Monitor method -- but if you need to pass a
synchronization object to your async callback, there's probably something
wrong with your design).

Without a callback, all that passing a "new object()" as the third
parameter does is exercise the garbage collector needlessly.

Obviously, it's my opinion that the above issues should be rendered moot
by a different approach to the question.  However, if you insist on using
this "async delegate" approach, you should at least do it as correctly as
you can given the situation.

Pete




== 2 of 2 ==
Date: Fri, May 9 2008 2:12 pm
From: "Peter Duniho"


On Fri, 09 May 2008 13:30:48 -0700, Jon Skeet [C# MVP] <skeet@pobox.com>
wrote:

> [...]
>> Should I be using some other mechanism to watchdog and break the hung
>> stream read?
>
> As Peter suggested, using a timeout is a good way - or you could
> potentially close the stream from a different thread. I don't know the
> details of how safe that is, but it's at least a possibility.

Closing an i/o object from a thread other than the one where the object is
blocking is a common technique, especially in network i/o (it's a standard
feature of all the socket implementations I've seen).  The OP still hasn't
provided any detail as to which class he's actually using, but assuming
it's a built-in .NET Framework class, I expect that closing the object is
not only safe, it's the right thing to do.

As I pointed out in my other reply, the timeout implementation Peter B has
suggested has a serious problem with it.  If you've got a class that
defines an API that supports timeouts, then yes...that's a great way to
go.  But if I read this message thread correctly, the specific problem is
that the OP is using a class that doesn't itself support timeouts.

Of course, without knowing the actual class he's using, there's no way to
verify that.

Adding a timeout in _some_ fashion is obviously the goal here, but using
the BeginInvoke() method on a delegate instance as Peter B suggests is not
a good general-purpose way to impose a timeout on some operation.  It's
probably fine for operations that you know _for sure_ will eventually
complete, and will do so in a reasonably short period of time (seconds,
maybe a few minutes depending on how often one might attempt such an
operation, and certainly not hours).  But it's completely unsuitable if
you're dealing with operations that may never complete.

As is often the case, if the OP would provide actual details on what the
code is really doing, it would be a lot easier to provide good advice.  So
far, we still don't know what i/o object is ultimately being used here, so
it's not really possible to tell him what the best timeout strategy might
be.

Pete





==============================================================================
TOPIC: Confused about the String Contains function
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/6343be990c83f93f?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, May 9 2008 2:02 pm
From: Jon Skeet [C# MVP]


SMJT <shanemjtownsend@hotmail.com> wrote:
> Thanks for all the replies and explanations.
>
> >> (whole+part).Contains( part) return true ALWAYS no? ...
> Fair enough, IF an empty string was part of the original string, but
> if a string has any contents, how can any part of it be empty?

There exists an empty string beginning at every place in the string. I
can't think of any definition of containment for which that's not true.

> >>"AnyOldText".IndexOf("")  == 0;
> yes but so does "AnyOldText".IndexOf("A") so which is it position 0 an
> empty string or a text stream?

Both, just as "An" is also at the start, and so is "Any".

> And "AnyOldText".IndexOf("",1)  == 1;  "AnyOldText".IndexOf("",2)  ==
> 2; "AnyOldText".IndexOf("",3)  == 3; etc ... So by that logic there is
> an empty string at each of these positions and text, which although
> theoretically true isn't exactly useful information.

Asking for the index of an empty string isn't a question which can
yield useful information though. Ask a silly question, get a silly
answer.

> >>"abc" + "" = "abc", it means that "abc" contains ""
> No it doesn't, it just means you concatenated nothing to the original
> string so I would expect it to remain unchanged.

The logic seems fairly clear to me: if x+y=z, then z contains y, right?
Now apply the same logic with x="abc", y="" and thus z="abc".

> >>("").Contains("")
> Yeah, ok that makes sense and I expected this to be the only time
> Contains returned TRUE.

Why?

--
Jon Skeet - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com





==============================================================================
TOPIC: What happened to CF_RTFNOOBJS and CF_RTF and CF_RETEXTOBJ
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/95dcafc9903a75df?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, May 9 2008 11:26 am
From: "AAaron123"


Before DotNet there were the formats:

// Clipboard formats - use as parameter to RegisterClipboardFormat()

#define CF_RTF TEXT("Rich Text Format")

#define CF_RTFNOOBJS TEXT("Rich Text Format Without Objects")

#define CF_RETEXTOBJ TEXT("RichEdit Text and Objects")



Are they still used by any MS programs like Word or WordPad?



If they are how are they handled by DotNET?





Thanks







==============================================================================
TOPIC: Accessing a web service - proxy problem
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/9ada854f53e5bb8f?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, May 9 2008 2:27 pm
From: "Tim Jarvis"


Jon wrote:

> Thanks Tim.
>
> You may also be interested in the reply that I had when I reposted on
> dotnet.framework.webservices.

Cool, thanks for that. That link that Steven sent you is useful.

Cheers Tim.


--






==============================================================================
TOPIC: Using delegates between main/sub threads
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/d2bd5cf1f1333654?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, May 9 2008 2:35 pm
From: "Ben Voigt [C++ MVP]"


> I have no idea what you mean here.  If you use Invoke() to call a
> method that updates internal UI state, then when Invoke() returns,
> you can be sure that what that method does -- updating internal UI
> state -- is done. If the method doesn't send a WM_PAINT, then the
> question of when the screen is updated or when a WM_PAINT message
> might be sent is irrelevant. That's not what the method being invoked
> does.
> Don't confuse what a method _does_ with what later implications that
> activity might have.  For example, the question of when a WM_PAINT
> message is sent is independent of when a method that updates internal
> UI state is done, and this is true whether you call that method
> directly within the correct thread, or call it indirectly from
> another thread using Invoke().

But by this definition, BeginInvoke is also synchronous.  It does not do
what the documentation says ("Executes a delegate asynchronously"), it posts
a request into a queue corresponding to the UI thread, then returns.  The
future execution of the delegate identified in that request is merely a
"later implication of that activity".

>
> Pete






== 2 of 2 ==
Date: Fri, May 9 2008 4:33 pm
From: "Peter Duniho"


On Fri, 09 May 2008 14:35:10 -0700, Ben Voigt [C++ MVP]
<rbv@nospam.nospam> wrote:

>> I have no idea what you mean here.  If you use Invoke() to call a
>> method that updates internal UI state, then when Invoke() returns,
>> you can be sure that what that method does -- updating internal UI
>> state -- is done. If the method doesn't send a WM_PAINT, then the
>> question of when the screen is updated or when a WM_PAINT message
>> might be sent is irrelevant. That's not what the method being invoked
>> does.
>> Don't confuse what a method _does_ with what later implications that
>> activity might have.  For example, the question of when a WM_PAINT
>> message is sent is independent of when a method that updates internal
>> UI state is done, and this is true whether you call that method
>> directly within the correct thread, or call it indirectly from
>> another thread using Invoke().
>
> But by this definition, BeginInvoke is also synchronous.

I can't tell whether you are deliberately or accidently confusing to which
"method" I'm referring, but you are.

Both Invoke() and BeginInvoke() are themselves synchronous.  That is,
neither method returns until it's done what it does.  All methods are like
this.

However, I'm not talking about those methods.  I'm talking about the
method that is invoked by either Invoke() or BeginInvoke().  The docs for
Invoke() don't say that it executes the passed in method asynchronously.
It simply says that it invokes the method on the control's owning thread.

You feel that the fact that the method isn't being invoked on the same
thread that's calling Invoke() means that it's implied that the execution
is asynchronous.  While I would be curious if you had an example of some
documentation describing an API that specifically executes a method, does
so asynchronously, and yet the docs don't state that specifically, the
fact is I simply disagree on what's a reasonable assumption or not.

We'll just have to agree to disagree.  But in any case, anyone reading the
documentation should be able to follow the logical concusion that, since
Invoke() returns the return value of the method being executed, obviously
it cannot return until that method has itself returned.

> It does not do
> what the documentation says ("Executes a delegate asynchronously"),

It does do exactly that.  The use of the word "asychronously" isn't
accidental there.  It's specifically being used as a shorthand way of
describing what BeginInvoke() does.

> it posts
> a request into a queue corresponding to the UI thread, then returns.  The
> future execution of the delegate identified in that request is merely a
> "later implication of that activity".

That's true.  And I wouldn't disagree that the docs would do well to be
more detailed about what BeginInvoke() really is doing.  However, the
phrase "executes a delegate asynchronously" is a reasonable approximation
and none of that contradicts what I wrote.

Frankly, I find no productive value in continue to argue about whether the
docs are clear enough or not.  If they confuse you, that's fine...please
feel free to suggest to Microsoft that they be improved.  There's nothing
wrong with improving documentation, even if they aren't ambiguous as-is.

Pete





==============================================================================
TOPIC: Evaluating numeric expressions
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/8f6d40de7fb368a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, May 9 2008 6:01 pm
From: Arne Vajhřj


PatrickS wrote:
> Is there an easy way in C# to take a string that contains an expression, say
> for example something like '(10 / 2) + 1' and evaluate it without having to
> parse the string myself and muck about with other stuff like operator
> precedence?

JavaScript has a nice eval function that can be utilized from C#.

See http://www.vajhoej.dk/arne/eksperten/div_2007_08/evaljs.cs for
a code example.

Arne





==============================================================================
TOPIC: Check if a Public Method exists for a form and execute it
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/944aa4e07285114c?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, May 9 2008 8:59 pm
From: Jeff


I need a way to do the following and cannot seem to find a solution via
google.

1. Have a method from the main app to get all open forms
2. Check each open form for a public method
3. If this public method exists execute it which will result in the
displayed form being updated.  There will be no data loss as the forms
will only contain listviews or readonly fields.

Regards
Jeff




== 2 of 2 ==
Date: Fri, May 9 2008 9:31 pm
From: "Peter Duniho"


On Fri, 09 May 2008 20:59:27 -0700, Jeff <jeff@[_nospam_].hardsoft.com.au>
wrote:

> I need a way to do the following and cannot seem to find a solution via
> google.
>
> 1. Have a method from the main app to get all open forms
> 2. Check each open form for a public method
> 3. If this public method exists execute it which will result in the
> displayed form being updated.  There will be no data loss as the forms
> will only contain listviews or readonly fields.

I don't really understand the last statement, as neither the question of
ListView instances or of readonly fields affects whether there could
potentially be data loss.

However, to address your specific question, you are looking for the
Reflection namespace.  You can use GetType() on each form instance to get
its actual type, and then use that Type instance to look for particular
members, including a method to invoke.

That said, using Reflection should be a last resort.  As an example here,
it would be much better if each form that might need this method to be
called instead implemented the method as an event handler.  Then the
application would define an event each form could subscribe to.  When the
event was raised, each form would then have its method executed
automatically, without having to go through all the reflection rigamarole.

If for some reason that and any other potential alternative isn't
possible, then reflection is your answer.

Pete