|
No. But considering I changed it to TCP/IP and it went faster, I must say it is an IPC problem (maybe the .Net implementation of IPC is the problem). And, considering my primary use was TCP/IP and IPC was only as a "faster" alternative, I simple dropped IPC support.
I think you must try with tcp/ip (or udp, like you said). If it works faster, the problem is in the protocol, not in your code.
|
|
|
|
|
Is there a way to make the System.Windows.Forms.WebBrowser view only? I am currently controlling a WebBrowser programmatically and am allowing the user to "watch" but the user is still able to interact with the control.
I am trying to find a way to disable the user’s ability to interact with the WebBrowser while still being able to view what is inside the control.
Thank you all in advance!
Matt
|
|
|
|
|
Maybe the enabled property?
|
|
|
|
|
Unfortunately, the Enabled property is not supported by the WebBrowser control. =(
Any other ideas?
|
|
|
|
|
|
Hi,
I'm trying to make my own LogonUI.exe (logon user interface[Vista and Windows7]) want to make all of things (login, lock, unlock, shutdown, restart) with my program (win32 form app) but i can't find any resource, article or something like this, can anyone help me a bit?
There is programs making this things, but they're not open source, please help.
Regards.
Orhan "Sehlor" KALAYCI
|
|
|
|
|
Create your exe with those functionality, then replace the value of shell in HKLM\Softwares\Microsoft\WindowsNT\CurrentVersion\Winlogon from explorer.exe to your exe name.
We generally do this to create custom explorer or KIOSK like interface...
Remember to place your exe inside %windir% (drive:\windows)
|
|
|
|
|
i m creating a window application on c# in which i m using crystal report option. I m getting fields data from the dataset, all is going fine but i m not able to increase the size limit of the fieldobject, there is a field in my dataset which is having text more than 500 hundred characters, when i run my application it shows only 500 characters and my whole data is not visible due to that.
so plz can anybody tell me how to increase the size to display text more than 500 characters.
thanks in advance
|
|
|
|
|
Hi,
Create a formula field which has the dataset field containing >500characters. drag it on the report where ever u want to show. right click on the formula field in report and choose format filed under the common tab check on can grow checkbox give ok.
hope this help.
|
|
|
|
|
hey karthik
thanks for ur valueable support
my problem solved now
actually i dont know how to create a formula field but my problem is solved with the help of text object. when i drag n drop the dataset field in the text object it works fine
thanks again
|
|
|
|
|
how nullable type different from normal type.i knew that for nullable type we can assign NULL value(specialy for value types)..i want to know what is the speciality in nullable type so that v can assign NULL to that...i am also want to know nullable types are another type or what?
|
|
|
|
|
This will tell you everything you need.
c# Nullable types[^]
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
Nullable Types can take Nulls. Generally Valuetypes couldnt have Null assigned to it, it should always assign default(type)
In case of Nullables, you can assign nulls
int? x = null;
if(x.HasValue)
int y = x.Value; // x.Value will point to original value.
So you can say Nullable types is just a wrapper. 
For further Enquery Read Here :
C# 2.0 Nullable Types[^]
Or
Working with Nullable Types in C#[^]
|
|
|
|
|
OK, so my facecious comment wasn't so helpful.
Primitive types (int, bool etc) are not nullable, the classic exception to this is string, which can be set to null.
Objects of type object and derived from object are nullable. Nullable types allow null values on "primitive" types (they also have HasValue property):
i.e.
int foo = null;
int? bar = null;
string baz = null;
string? quux = null;
Nullable<string> foo1 = null;
object bar1 = null;
MyClass baz1 = null;
Personally, I'd stear clear of nullable values where possible, as you will need to perpetually check the value is not null and other types of evil ensue.
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
keefb wrote: Personally, I'd stear clear of nullable values where possible, as you will need to perpetually check the value is not null and other types of evil ensue.
yaah ... me too .. 
|
|
|
|
|
There are plenty of good uses for Nullable.
Think of a case when you have an optional value, (e.g. a field in a database), what better way to indicate a missing value than with null? Oftentimes, people use -1 (or some other reserved value) to indicate that something is missing; using nullables is an elegant way to indicate ommision without eating into possibly valid values.
|
|
|
|
|
vtpdawg wrote: There are plenty of good uses for Nullable.
True, and as I said, I wouldn't use null unless I had to.
Where a value is truly unkown then I would use a null as you suggest, but instances of this are less common than represented in code bases I have seen. If you see a nullable value you should really think twice to ensure it truly is unkown.
A case in point is the -1 example you give. This is my view is preferable than having rogue nulls hanging around. From the DB point of view, anyone writing SQL against a table that has nullable columns has to be aware that null is a possibilty. Wheras say -1 relates to an "Unset" state, this is still normally a valid state .
On the code front, I remember reading somewhere that 50%(this seems too high, but it is a large percentage) of all exceptions are null reference exceptions.
The is lots of literature out there on both sides of the argument, personally I think nulls are evil, but sometimes a necessary one.
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
What do you think of reference types? They should be checked for null as well. Plus, there are many more reference types than value types.
|
|
|
|
|
True, and this is a deficiency in the framework in my opinion( see my other post on this thread for a partial explanation why, and I again stress this is my opinion, others differ and anyone reading this should, as ever, evaluate and form their own). Additionally, reference types passed into a function are mutable by the function, which can lead to unexpected consequences if that method is poorly implemented. Again this is one of the things I think languages like c++ handle better.
I'm certain the .net framework designers had good reasons to choose the reference types over value types when designing the language, just from my point of view it would have been nicer if they hadn't. Saying that, I dare say Microsoft put a few bright minds on the framework team 
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
I don't see how if (val == -1) is much different than if (val == null)
null is not something to be feared, the prudent developer should just be in the practice of always considering null when dereferencing objects. You mention "rogue nulls hanging around" like they're some loitering punks harassing passerbys
That being said, I've only ever used nullables in data access layers (LLBLGen and LINQ actually generate code with nullables) and a specialized encoding library where it was perfectly valid to omit property values, including value types.
|
|
|
|
|
vtpdawg wrote: I don't see how if (val == -1) is much different than if (val == null)
Of course, if you take this as an example there is little difference. Consider the example of the number indicating a "status" of some kind to display on the UI. One implementation (albeit artificial and not necessarily the best) would be to reference with number with a dictionary:
Dictionary <int,string> lookup;
public void SetupLookup()
{
lookup = new Dictionary <int,string>();
lookup.Add(-1, "Unkown");
lookup.Add(0,"Naughty");
lookup.Add(1, "Nice");
}
public void string Lookup(int foo)
{
return lookup[foo];
}
public void string Lookup2(int& foo)
{
if(foo.HasValue)
return lookup[foo];
return "Unknown";
}
This example isn't perfect, but serves to illustrate the point. Now, we need to handle the null properly in the nullable type case . Once you decide to put the nullable type in, this sort of checking necessarily propagates throughout the code if the code is written to be robust. Additionally, there are fewer problems binding non-nullable types as you can (as in the above example) resolve -1 to something directly.
vtpdawg wrote: You mention "rogue nulls hanging around" like they're some loitering punks harassing passerbys
In a database context, this is exactly what they are like.
vtpdawg wrote:
null is not something to be feared, the prudent developer should just be in the practice of always considering null when dereferencing objects.
Agreed, but it is surely better to factor these out by design? One of the things I don't like about c# is the fact that objects are nullable by default (unlike c++) because we have to write a boilerplate code to allow for this.
The point I was trying to get across was just that nulls are best avoided and rarely needed, not that nulls should never be used. There are good counter arguments to everything I have said here, many of which I have sympathy with, it's opinion that the arguments in favour of avoiding nulls outweigh these (Others of course disagree!).
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
I guess this is a case where programming is subjective. I actually prefer your Lookup2 implementation. I agree that one should not propagate special cases throughout their code, I'm a subscriber to the "say it once" approach; as long as this principle is followed, I'd not complain about either implementation.
“The best thing about a boolean is even if you are wrong, you are only off by a bit.”
(Anonymous)
|
|
|
|
|
I think that I didn't explain myself properly last night (my previous message was posted after midnight, so hopefully I get some slack !) in my code sample. Lookup(int foo) isn't needed, as lookup[foo] can be called inline, whereas Lookup2(int& foo) would have to be implemented at best. Also, internally Lookup(int foo) is one line of code whereas Lookup2(int& foo) has 3 AND a branching if statement (increasing cyclomatic complexity), both of these factors make my developer's Spider-senses tingle.
I agree this is subjective, as I have said in previous posts, there are good arguments for and against the nullable types we are discussing. (I was in the pro-camp for a fair while).
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
You did a lot better job explaining yourself this time
Another appropriate use of nullables can be seen in a recent post:
Using LINQ to Calculate Basic Statistics[^] Here, null is used as a return for standard deviation if the set to calculate is invalid (e.g. null, empty, or < 2 elements). I think I tend to like that better than an out parameter and a boolean return value, and is certainly preferable to returning a valid double in an error case. I guess one could argue that a negative value would be ok (since std dev is >= 0), or an exception should be raised...
“To err is human, but to really foul things up you need a computer.”
-Paul Ehrlich
|
|
|
|
|
vtpdawg wrote: Here, null is used as a return for standard deviation if the set to calculate is invalid (e.g. null, empty, or < 2 elements).
The Mode method, this could be a valid use of null as a set like {1,2,3,4} doesn't have a single modal value (unlike {1,1,2,3,4}. Null isn't "zero" or an empty string or somesuch, it really denotes the abscence of anything. Though equally could implement the Method so that it throws an exception if the set doesn't have a mode. The author of the article states that he returns null as this is what Excel does. You pays your money, you takes your choice on this I think.
vtpdawg wrote: Here, null is used as a return for standard deviation if the set to calculate is invalid (e.g. null, empty, or < 2 elements).
This is a different matter, the code definately should throw an error, as you can't perform SD calcs on such sets.
I know that Exceptions ring alarm bells as the perception is that they have bad performance. This is indeed true if a debug build is made, however when a live build is made the performance is close to events (which is, after all what they are underneath).
vtpdawg wrote: I think I tend to like that better than an out parameter and a boolean return value, and is certainly preferable to returning a valid double in an error case.
Agreed, that would be an ugly solution, and as I have [hopefully successfuly] explained an unecessary one as it can be handled via exception.
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
