|
i downloaded an example of property grid custom properties.
this is the example link:
http://www.codeproject.com/cs/miscctrl/Menu_in_PropertyGrid.asp
when i clicked on "sturct" property i get a button on the right side of the property.
i dont want this button to be shown.
how do i do it?
waiting for your answer.....
thanks and have agood day
|
|
|
|
|
There is a board at the bottom of the article. If you place your question there than the author will be automatically notified. He probably knows best how to help you.
|
|
|
|
|
Sometimes (less that 1% of the calls) I am getting “System.Runtime.Remoting.RemotingException: Port is Busy: All pipe instances are busy” on remote method invocation when using IpcChannal.
Has anybody experienced the same problem?
Suggested solutions?
|
|
|
|
|
Maybe trying to disconnect/hand off from the ipc channel will resolve this.
|
|
|
|
|
Hello there,
I'm looking for a method to convert an object to Guid type and vise versa.
Thanks.
|
|
|
|
|
Please don't cross post !
My english is not so good. Please, correct my errors.
Best regards, Alexey.
|
|
|
|
|
If i call Web Service from same server it's working fine. If i try to call the Web Service from another server,i am getting this following error.
Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\39_bmero.0.cs' could not be found.
error CS2008: No inputs specified.
sathiya
|
|
|
|
|
I'm going to guess that when calling it from the same server, it uses Windows Authentication. The ASP.NET runtime then uses your credentials to write the C# code that it generates to do the XML serialization, which it then calls the C# compiler on to generate an assembly to load.
When you call it from another server, it's probably using anonymous authentication, which means that the serializer code is running as the ASPNET user (Windows 2000, XP, by default) or the NETWORK SERVICE account (Windows Server 2003). The actual account used can be modified in web.config on 2000 and XP and by changing the application pool settings on Server 2003. I suspect that the error is occurring because the Access Control List on the C:\Windows\Temp folder doesn't allow this user to write to it. To change this, right-click the folder in Explorer, go to the Security tab, click Add, select the appropriate user, and check Modify in the Allow column.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I have been developing some extensions to bollwerkj's article "How to use Managed C++ to Automate Excel" (http://www.codeproject.com/managedcpp/ExcelwithMC.asp[^]) and one key line is
using namespace Microsoft::Office::Interop::Excel;
A couple of weeks ago, I loaded the new Windows security updates, and now I am getting compile errors that say "Interop is not a member of Microsoft::Office." Anyone have any idea how to undo what I've done and get this back? (I don't know for sure that these two events are connected.)
I went back to through the article and re-installed the PIAs, but that didn't fix anything. The files were all available. Has anyone else run into this kind of problem before?
Any suggestions will be greatly appreciated.
Thanks,
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
I have a plug in that I load into a new appdomain, and before I create the domain, I set the AppDomainSetup.ApplocationBase directory to point to where all the assemblies which constitute my plug in are.
This works just fine, and the new domain obediently goes away and loads the satellite assemblies in. But I also have a text file I want to read in, but when the plug in tries to do this, it searches the primary domains bin\debug folder, not the one specified in the ApplicationBase folder.
Anyone know how I can use the ApplicationBase as the working folder for the domain as well as the assembly search path?
Regards,
Rob Philpott.
|
|
|
|
|
The ApplicationBase property does NOT change the current directory for file operations. It only affects the loading of assemblies for that AppDomain. An application cannot have more than one "current directory", one for each AppDomain is not possible, and using it is considered an unreliable practice anyway. Change your code to get the path to the .EXE (Application.StartupPath), then use the Path class's Combine method to create fully qualified paths to the plugins.
Dave Kreskowiak
Microsoft MVP - Visual Basic
-- modified at 11:20 Tuesday 18th July, 2006
|
|
|
|
|
Nice one Dave,
Thanks for that - a very precise answer on a subject not many (including me) know about. When you say 'an application' cannot have more than one current directory, do you refer to a Windows process?
Regards,
Rob Philpott.
|
|
|
|
|
Yep. An application, or Process, can have multiple AppDomains, but only one "current directory".
Myself, I follow the philosophy of leaving nothing to chance. I always build and use fully qualified path names, even when then files are in the same path as my application.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
You could set the static Environment.CurrentDirectory property to the same directory as the ApplicationBase.
:josh:
My WPF Blog[^]
|
|
|
|
|
Hi all
I'm writing a simple form which is a launcher of a game using C# with .net framework.
What problem I met is, I need to place some transparent buttons in the form which contains a playing AVI video in the background, but the video in the transparent part of those buttons cannot be properly displayed.
I used a panel to hold the AVI video (using Microsoft.DirectX.AudioVideoPlayback) and a PictureBox to hold the transparent image (PNG format). I did set the background of the PictureBox to transparent, but the color of the transparent part of the Image seems as same as the background color of the form.
Can you help me about this? thanks!
|
|
|
|
|
You might be able to work something out by using the backcolor and forecolor options for the controls and set the color to transparent. ex:
control1->backcolor = Color(0x00000000);
p.s. the code sample is in c++, although it should be close enough for you to work with it in c#, and the color call is in system.drawing.dll
|
|
|
|
|
You can use a transparent (TransparencyKey = BackColor) form above your panel.
|
|
|
|
|
Hi all,
I've recently had to work on a .NET web application. Now, although I've been familiar with .NET for approximately a year now, I'm primarily a Java developer. And while I think .NET is a great idea, there is one thing I don't quite understand about it -- the way exceptions are handled. In particular, I'm dissapointed by the lack of checked exceptions. A method does not need to declare that it may throw an exception, making it harder to manage the propagation of exceptions in your programs.
Perhaps a simple example to demonstrate...
Java:
static void myReadLine(String filename) throws IOException {<br />
BufferedReader reader = new BufferedReader(new FileReader(filename));<br />
return reader.readLine();<br />
}
C#:
static void MyReadLine(string filename)<br />
{<br />
StreamReader reader = new StreamReader(filename);<br />
return reader.readLine();<br />
}
It's pretty obvious what both methods are doing, and that they are doing it in pretty much the same way. The main difference is in how those methods can now be used. In C#.NET, you can call MyReadLine() from anywhere in your code and everything will happily compile. If things go wrong and an System.IOException is thrown in that method, then unless you've done your homework and surrounded the call to MyReadLine() with a try-catch block, your application will crash. With a pretty stack trace printed on the screen. Ungracefully.
In Java, the code will not even compile unless you are explicitly catching that exception when calling myReadLine(). An IOException is a checked exception in Java -- meaning that if it's ever thrown, it must be caught somewhere in your code. Other exceptions, such as, say NullPointerException, are run-time exceptions and do not have to be explicitly caught (although sometimes it's not a bad idea to do so). In .NET, it seems, all exceptions are considered run-time.
Even if you happened to know that StreamReader.ReadLine() throws an exception, there's a fair chance that some methods in your code could throw exceptions without you even knowing it. And if they can, then they will -- at the worst possible time, naturally. So your options are either keep your fingers crossed, or trawl through the documentation, checking for possible exceptions for each method your code is calling. Neither option is particularly appealing. Nor is catching the general System.Exception always a good idea. Whenever something has gone sour, the code that makes the sun shine again should know exactly what when wrong and exactly what to do about it. Catching a general exception just tells your program something went wrong -- no more, no less.
Why am I writing this? If you've read this far, you'll probably agree that sure sounds like a whinge. And you'd be right. But there's more to it. I'd like to ask:
Can someone cast light on why are exceptions being handled this way in .NET? What are the advantages of treating all exceptions as run-time exceptions?
Is it something that you just learn to deal with as a .NET developer? How do you deal with it?
Cheers,
Misha
|
|
|
|
|
Yes there is a rationale behind this.
Anders Hejlsberg (Turbo Pascal inventor, Delphi Lead Architect at Borland and now lead C# architect at MS) does explain why Javas checked exceptions are a nice concept but do break in big projects.
http://www.artima.com/intv/handcuffs.html
HTH,
Alois Kraus
|
|
|
|
|
Thank you. That is a very insightful article. It sheds a lot of light on the topic. The author makes points that are both relevant and valid. While I can't say I agree with all of them 100%, I can now see that there is indeed more than one way to skin a cat.
Of particular interest is his approach to exception handling -- heavier use of the try-finally to free any acquired resources, and a centralised exception handler to actually deal with the exception.
After reading that article, however, one particular paragraph bothered me:
From the article: But that said, there's certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks... But I think we can certainly do a lot with analysis tools that detect suspicious code, including uncaught exceptions, and points out those potential holes to you.
Now, I would like to know -- what publicly available tools like that are out there?
Thanks.
Cheers,
Misha
|
|
|
|
|
misha1983 wrote: what publicly available tools like that are out there?
I don't know of any.
In fact I opened an FR with MS that would have the XML documentation created include any exceptions thrown inside the documented method, just to be sure that they get into the documentation.
My Blog[^]
FFRF[^]
-- modified at 10:33 Friday 14th July, 2006
|
|
|
|
|
Static code analyzers like Reflector (it has a very good API but nearly no docu) can do this to a certain degree. You will never get 100% coverage since today software is plugable/configurable. There is no way to find out what module you did configure into you software. But for a good overview if some big holes are missed static code analyzers (FXCop should also be able to do this to a certain extent) they are surely useful.
Yours,
Alois Kraus
|
|
|
|
|
misha1983 wrote: Can someone cast light on why are exceptions being handled this way in .NET? What are the advantages of treating all exceptions as run-time exceptions?
I would say that the checked exceptions in Java are still run-time exceptions (they get thrown at run-time, not at compile time) it is just that Java has the ability to explicitly declare which exceptions a method will throw as part of the method signature and the compiler just ensures they are either caught or become part of the signature of the calling method.
I would say that the best discipline would be to ensure that, when you document the code, you define which exceptions a method will throw in the documentation. Intellisence in Visual Studio will read the XML documentation and generate appropriate tool tips while you are typing the method name to remind you that exceptions are thrown.
misha1983 wrote: Is it something that you just learn to deal with as a .NET developer? How do you deal with it?
I've never really thought about it before. I was a C++ developer since 1992 before .NET came along and it never had checked exceptions either. In fact, in C++ you could throw any object you liked as an exception - which is probably a worse situation.
Scottish Developers events:
* .NET debugging, tracing and instrumentation by Duncan Edwards Jones and Code Coverage in .NET by Craig Murphy
* Developer Day Scotland: are you interested in speaking or attending?
My: Website | Blog
|
|
|
|
|
Colin Angus Mackay wrote: it never had checked exceptions either.
C++ does have exception specifications with the same syntax. An exception specification in C++ provides a solution that can be used to list the exceptions a function may throw with the function declaration, but it does not force the caller to write code to catch the listed exceptions. I like the C++ way 
Best,
Jun
|
|
|
|
|
Apart from Anders's article at Artima there has been lots of discussion about this (and research) elsewhere on the web. The general consensus seems to be that checked exceptions seem like a good idea at first, but not such a good idea eventually!
However, Spec#, MS's research language, which is a C# superset, does have checked exceptions and I think they provide a rationale for this, given the extra features of Spec#! So maybe some form of them may be rolled back into C#! Confusing, eh?
Kevin
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
