|
Then "trust" the local server following the same steps.
|
|
|
|
|
Hi,
that will delete the localhost as trusted server and my first problem is rentering 
ty
|
|
|
|
|
You can add multiple entries separated with a comma.
|
|
|
|
|
Hi,
ty very much for u help.my website works well.but still some bugs related surely to a compatibility a compatibility of Javscript and FireFox.The main is that when I RAPIDLY naviagte on my website, all works well but after some time (<= 1mn), all is blocked and no navigation allowed. that stufies me veryyyyyyy much
ty
|
|
|
|
|
hiii
iam working on c# windows Application on vs 2010
i use components called devcomponents on old project that work on vs 2005
i try to use these dll in vs 2010 project
but i have that error
The type or namespace name 'DevComponents' could not be found (are you missing a using directive or an assembly reference?)
i add these dll as refernce but i can't use it
md_refay
|
|
|
|
|
right click on the toolbox then click add tab name it (devComponent)
then right click on it click choose item then browse,select your DevComponent and then click open.
the tools will load to your toolbox
go to the solution explorer right click on references click add reference again go to browse and select your devcomponent and ok
go to the main toolbar click project and the click on your program properties like(windows form application1 properties) then change the target framwork to .NET Framwork
|
|
|
|
|
How do I open a form to a different container then the one currently in use, using the following.
I have a video card which gives me the ability to view data on 2 separate monitors.
I setup two Mdi Containers FormContainerA and FormContainerB.
In FormContainerA there is FormA with a button on it to open another form FormB which I wish to open in FormContainerB.
In the constructor of FormB I used the following code.
FormContainerB B = new FormContainerB();
this.mdiParent = B;
This does not seem to be working.
Can anyone hlp me with this problem.
Thanks in advance,
Michael
modified on Wednesday, August 3, 2011 11:06 PM
|
|
|
|
|
If you have already constructed the two forms, then you need to refer to the instance you are displaying. Using the new keyword constructs a new instance, so rather than attaching your form to the displayed container, you attach it to the new one.
You need to use the original FormContainerB instance.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
The problem is, you are creating a new instance of FormContainerB() and making it the parent of your form. You must have one instance of FormContainerB for the entire application. You can acheive this using the Singleton patten like this:
public class FormContainerB : Form {
private FormContainerB _instance;
private FormContainerB() {
}
internal static FormContainerB Instance {
get {
if (_instance == null) {
_instance = new FormContainerB();
}
return _instance;
}
}
}
And then you can set it as parent to your forms like this:
this.MdiParent = FormContainerB.Instance;
modified on Thursday, August 4, 2011 5:01 AM
|
|
|
|
|
I have a wmi enumerator, and I'm looking to build one for exchange wmi commands and I can't seem to get it to work. Below is my code.
As some background as to why, I am trying to query some things in exchange 2007 that are not stored in the registry and that I think are in the exchange database. An example of values I'm looking for are owa (Default Web Site) Properties inside of the EMC under server config --> client access --> owa (Default Web Site) Properties and the tabs underneath there.
Thanks for reading!
private void wmiExchangeEnumerator(string wmiSearchClass)
{
try
{
ManagementScope scope = null;
ManagementObjectSearcher searcher = null;
ConnectionOptions options = new ConnectionOptions();
if (textBox4.Text != "")
{
string serverName = textBox4.Text;
scope = new ManagementScope(GetStandardPath(serverName), options);
scope.Path = new ManagementPath(@"\\" + serverName + @"\root\MicrosoftExchangeV2");
scope.Options.Impersonation = ImpersonationLevel.Impersonate;
scope.Connect();
ObjectQuery query = new ObjectQuery("SELECT * FROM " + wmiSearchClass);
searcher = new ManagementObjectSearcher(scope, query);
}
else
{
scope = new ManagementScope();
scope.Path = new ManagementPath(@"\root\MicrosoftExchangeV2");
scope.Options.Impersonation = ImpersonationLevel.Impersonate;
scope.Connect();
searcher = new ManagementObjectSearcher("SELECT * FROM " + wmiSearchClass);
}
ManagementObjectCollection results = searcher.Get();
textBox5.Text += ("There are " + results.Count + " items in " + wmiSearchClass) + System.Environment.NewLine;
int count = 0;
foreach (ManagementObject result in results)
{
textBox5.Text += ("=============== " + wmiSearchClass + "[" + count + "] ===============") + System.Environment.NewLine;
count++;
PropertyDataCollection pdc = result.Properties;
foreach (PropertyData pd in pdc)
{
string name = pd.Name;
object obj = pd.Value;
if (obj != null)
{
string[] sa = obj as string[];
if (sa != null)
{
string ss = string.Join("\";\"", sa);
textBox5.Text += ("SA " + count.ToString() + ": " + name + " = string[] = \"" + ss + "\"") + System.Environment.NewLine;
}
else
{
textBox5.Text += (count.ToString() + ": " + name + " = \"" + obj.ToString() + "\"") + System.Environment.NewLine;
}
}
}
}
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
|
|
|
|
|
I need to write a web related search Engine in C++ or C#. I am more comfortable in C++, but I would also like to master C#. My question, is there any clear advantage of doing in one than the other?
Thanks
|
|
|
|
|
One obvious advantage of course is that you will not learn C# if you do it in C++.
Of course there is also a difference between C++ and managed C++. But if you use the former then you are more likely to learn about nitty gritty details of network details.
|
|
|
|
|
Are you saying learning C# is a disadvantage?
|
|
|
|
|
C# is a more modern language, which produces more reliable code. It has a vast class library which reduces the amount of code you have to write. Development is faster in C#, and it will be a requirement for many jobs for the foreseeable future.
You should take an opportunity to learn it.
|
|
|
|
|
Alan Balkany wrote: C# is a more modern language
Based on that everyone should immediately move to F#.
Alan Balkany wrote: which produces more reliable code.
Only way to produced significantly more reliable code is to actually write code that is reliable. Language choice doesn't lead to success at that. People make the difference.
Alan Balkany wrote: It has a vast class library which reduces the amount of code you have to write
Pretty sure C++ has a vast number of libraries to access. They just don't come with the language.
Alan Balkany wrote: Development is faster in C#,
Again people make the difference.
Alan Balkany wrote: and it will be a requirement for many jobs for the foreseeable future.
Which is true for C++.
In terms of employability if one knows C++ or C# and then learns SQL is probably going to have more opportunities, overall, than if one just learns another OO language.
|
|
|
|
|
"Based on that everyone should immediately move to F#."
Its a factor; not an absolute. You don't drive a Model T, do you?
"Only way to produced significantly more reliable code is to actually write code that is reliable. Language choice doesn't lead to success at that. People make the difference."
Have to disagree here; it's much less likely to have certain types of errors in C#, such as undetected buffer overruns. If the only factor is people, why is development in assembly language so slow? The tools you use make a big difference.
"Pretty sure C++ has a vast number of libraries to access. They just don't come with the language."
Locating and integrating them increases the amount of work you have to do to get a solution. There's no guarantee of mutual compatibility or any minimum level of reliability with a library from an unknown source. Then there's the versioning problem that's greatly reduced when all the libraries are integrated with the language release.
I think use of C# will increase, while use of C++ will decrease in the coming years. C# is a better bet at this point, in my opinion.
|
|
|
|
|
Alan Balkany wrote: Its a factor; not an absolute. You don't drive a Model T, do you?
Got to love those analogies...
Exactly how many deliveries on a daily basis do you see via Model T?
What percentage from all mechanics will work on them?
How many auto parts stores sell parts for them?
In comparison the following study, which has been going on for years, and of which has the best methodology that I have ever seen demonstrates that C# certainly isn't one that you want to bet on for being the most popular in the near future.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html[^]
Alan Balkany wrote: Have to disagree here; it's much less likely to have certain types of errors in C#, such as undetected buffer overruns. If the only factor is people, why is development in assembly language so slow? The tools you use make a big difference.
Are you claiming that Assembly is comparable to C++?
And having programmed in C++ for many years the last time I had a pointer error was before there was an ANSI standard. You are aware that there are now and have been for many years (again before ANSI C++) tools which are very effective at discovering pointer errors?
Alan Balkany wrote: Locating and integrating them increases the amount of work you have to do to get a solution.
Huh?
Are you suggesting that C++ programmers don't know how to use google?
Or that there are not libraries that are very effective which do not come with the standard .Net API? As an example do you use a logging library? For that matter have you ever used the Enterprise library or any of number of other libraries from Microsoft which do not come with the .Net API?
Alan Balkany wrote: There's no guarantee of mutual compatibility or any minimum level of reliability with a library from an unknown source.
Presumably you mean in comparison with .Net API? Are you claiming you haven't found bugs in that? Or at least very odd things? I certainly have.
One advantage to other solutions is that there is at least a chance that I some how I can get a solution in the near future. For example I might be able to get the source code (free or at a reasonable price) and fix it myself. Or I might point out the problem to a 3rd party vendor and have a fix in a very short time (point of fact I have had that happen.) Conversely the only way I expect to have that happen with the .Net API is if a give a very large sum of money to Microsoft. (To be fair that would be exactly the same situation with Oracle as well.)
Alan Balkany wrote: Then there's the versioning problem that's greatly reduced when all the libraries are integrated with the language release.
No idea what you are talking about. If I compile with a C++ compiler with the standard C++ libraries then those libraries go in my install. If I update then so do the libraries.
Best I can suppose is that you are referring to the versioning problem that some people experienced across all Microsoft languages when they were not careful in the past. That however, as per my point about people, is caused because people (not languages) didn't know what they were doing.
Alan Balkany wrote: I think use of C# will increase, while use of C++ will decrease in the coming years. C# is a better bet at this point, in my opinion.
Actual statistics suggest otherwise. If you want to make that bet then Objective-C is much, much more likely to be the winner.
|
|
|
|
|
Software2007 wrote:
Are you saying learning C# is a disadvantage?
Could be.
For example
- Using TCP in C++ will require learning more about that versus C#.
- One is more likely to learn about how the OS manages memory if one uses C++.
- One is more likely to learn about how the OS manages other types of resources if one uses C++.
Doesn't mean that one will not learn those with C# but rather that it is more likely that with C++ will need to learn about those in detail.
|
|
|
|
|
Hello
I am calling a piece of code in all my aspx.cs pages, which is like an error trapping class.
Can I create an actual class, and then include this class in my aspx.cs pages, so if I do have a change I can make this change in one place, in this one class instead of all my aspx.cs pages?
How would I go to call this class?
I was able to create a stand alone class but how to include in my aspx.cs pages?
Thanks!
|
|
|
|
|
Inheritance will solve your problem. You create a base page based on the built-in Page object:
public abstract class MyPageBase : System.Web.UI.Page {
}
Then in your codebehind files, you can inherit from the class:
public partial class DefaultPage : MyPageBase {
}
|
|
|
|
|
If you are really trying to implent a top-level exception handler to trap all errors,
you might like to use the Application_Error method in Global.asax. There is an whole knowledge base article about it here[^]. This has the added advantage of trapping some extra [mostly unlikely] errors.
In all other cases Matt Meyer's answer is excellent.
[Edit]
Replaced bizzare language with a more commonly used one called English, and changed the content so it says what I mean rather than simply meaining what I say. </Idiotness>
|
|
|
|
|
I have 2 list collections as below
List1
115
100
150
List2
115
100
now i need to check both of above list and need to get answer for matched ,
for example :
115
100
both matched, i need to achieve this how can i do it ?
|
|
|
|
|
C# 3.5? list1.Intersect(list2)[^] (it's an extension method in System.Linq)
If not, it's trivial to produce a naive implementation which will be fine for small lists:
IList<T> Intersection<T>(ICollection<T> one, ICollection<T> two){
IList<T> r = new List<T>();
foreach(T t in one)
if(two.Contains(t)) r.Add(t);
return r;
}
|
|
|
|
|
You've been around long enough to know and understand the forum guidelines. DON'T REPOST. You asked this same question four hours ago in the C# forum, it has nothing to do with ASP.NET. If you didn't receive an answer, wait. Don't repost.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I think he should delete the other one, not this one, though. C# forum is the correct place for it, the other one is misplaced (and I didn't see it there since I don't read the ASP.NET forum  ).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
