|
My plotting Panel is perfectly smooth, however I can't compare, I never do it the Form way, as
1) it isn't really object-oriented
2) too many things probably are going on with Forms.
|
|
|
|
|
I just wonder if a (dependency)Object can be made aware of data bindings, e.g. if it acts as binding source.
It would be nice to get an event from somewhere to realize that someone bound to my object and to get the path that was used on it. So the object could see that a binding to one of it's public properties was created.
But seems like the .NET framework offers no such capabilities for data binding. 
Any ideas or suggestions how to create something comparable?
Cheerio,
Don Rolando
|
|
|
|
|
Hi
I'm a newbie struggling with a picturebox.
At construction time I load a jpg image into a picturebox and I have 3 radio-buttons that dictate what what is drawn in the GUI. When the picturebox is enabled & visible at construction time then it stays visible even if I make it invisible later by pressing a radiobutton (picturebox1.visible = false) .
Can someone please tell me what I'm missing?
Regards
Tom
|
|
|
|
|
Hmm, just solved it myself...
when I replace:
BitmapCanvas.Visible = false;
With:
this.BitmapCanvas.Visible = false;
Then I can make the visible picturebox go invisible!
Wonder why that is needed?
Probably a no-brainer
Thomas
|
|
|
|
|
This problem happens when you have a parameter or variable in a method that has the same name as the field of a class, such as:
class MyClass
{
private int value;
public MyClass(int value)
{
this.value = value;
}
}
You can tell by hovering the mouse over value in the code editor.
|
|
|
|
|
bimbambumbum wrote: BitmapCanvas.Visible = false;
hover BitmapCanvas, right-click for "Go to definition" and see if that is what you expect it to be.
|
|
|
|
|
If my applications (mainly WinForms, C#) work in older versions of .NET Framework, should I publish them in older or new version? Is there any criteria that I should look for?
Thanks in advance!
|
|
|
|
|
It really depends on the kind of application and who it is intended for.
If you do not need any features of the latest version and if you do not use any libraries built with the latest version of the framework, then it might be appropriate to build your project for an older version of .NET.
For example .NET 3.0 is pre-installed on all Windows Vista computers and .NET 3.5 ships with Windows 7. Therefore if you chose .NET 3.0 as your target framework, there will be more users able to use your application out of the box.
|
|
|
|
|
Fresh-Grass wrote: If my applications (mainly WinForms, C#) work in older versions of .NET Framework, should I publish them in older or new version? Is there any criteria that I should look for?
Deploy them against the version you have tested on. Later versions may contain fixes/changes to behaviour that you rely on - the argument here is that you should really test on the latest version with Service Packs that you can.
|
|
|
|
|
I had an issue recently in 2.0 that was fixed in service pack 1. I then found that 2.0 SP1 is bundled as part of 3.5 SP1 so if I was starting a new project I would not bother with anything lower than 3.5 SP1
If you want a widest potential audience for your application, it is probably best to stick to 2.0 however, as it is part of 3.0 and 3.5, and therefore will be on more machines than any other version.
The only versions worth upgrading from, and it is an upgrade not just recompile, is from 1.0 and 1.1. Even Microsoft are not supporting them much these days.
|
|
|
|
|
|
Hi,
1.
when you are creating a managed-code project (say an EXE file mainly consisting of C# code), then the only stuff you can "Add a Reference" is more managed code; unmanaged aka native code DLLs can be used through a technology known as P/Invoke; this does not rely on any "reference", Windows will locate those native code libraries just like it always has, by looking for them in a predefined set of folders (see the PATH environment variable).
2.
P/Invoke is pretty complex. I'm working on a little article series on the subject, part 1 of it is available here.
3.
There is an alternate route, where you would build a managed C++/CLI wrapper to the native code (using another "technology" known as "it just works"). Some are strongly in favor of that route, I'm not, as I'm not very active in C++ and don't want to rely on a third language to connect the two languages I do use most (C# and C).
|
|
|
|
|
Hi Luc
Thanks for your support.
I managed to get the FFT working as I found a P/invoke FFTW project I could "borrow" from.
I appreciate that you spend time writting your reply to me.
Will take a look at your article and try get familiar with P/Invoke.
Thanks again
Tom
|
|
|
|
|
Hi All,
I got a requirement to import and export the data from different databases, flat files, csv files and xml files. I am unable to decide whether I sould use typed datasets and SSIS for the same. This is first I am getting this kind decision making responsibility.
Can anybody give me any suggestions, or links to calculate the pros and cons of both methods. Any link or advice or anything will be helpfull. In this mean time I will google the this.
Thanks & Regards,
Md. Abdul Aleem
NIIT technologies
|
|
|
|
|
Hey geniuses, it's me again. Google has failed me so I humbly come to you with a question about how .NET performs string comparisions.
A tiny bit of background, I'm reseaching how the use of string constants is better than hardcoding string literals (beyond good coding practice).
I wrote this code to check the various ways .NET handles strings.
string s = "howdy";
if (HELLO_W == "hello")
{
Console.WriteLine("condition 3");
}
And then checked the IDL with ildasm.exe
IL_0033: ldstr "howdy"
IL_0038: stloc.1
IL_0039: ldc.i4.0
IL_003a: stloc.2
IL_003b: nop
IL_003c: ldstr "condition 3"
IL_0041: call void [mscorlib]System.Console::WriteLine(string)
IL_0046: nop
So where is the string comparision? When I compare two ints, I see the comparision command "ceq".
As always, I appreciate your insights and am not afraid to kiss a little butt to get it. 
|
|
|
|
|
If HELLO_W is a constant, then the result of the comparison is known at compile time and it will always be the same. I believe the compiler is smart enough to remove such unnecessary conditions...
You might get different IL code depending on the compiler settings (Release/Debug).
|
|
|
|
|
Yep, that was it. Thank you. Now I'm getting this.
IL_004a: call bool [mscorlib]System.String::op_Equality(string,string)
Rookie mistake.
|
|
|
|
|
|
Can't believe I am asking this, and I admit I am lazy right now... I just have not had the chance to look into it or test it yet today so I figured I would throw it out there and see what folks have to say...
By the way, I am interested in this even in non-dot-net based languages, but didn't want to cross post 
When you fire up a list of threads are they always guaranteed to REALL fire up in the order that you start them in or could the scheduler for some reason decide to place one above another, keeping in mind that for my contrived example they all are the same code that is...
Just wondering if anyone has ever tried this and seen odd results, or at least results that made them go hmmm for a second... My assumption is hat the process of starting a thread is sync so they are always going to get started in the same order, no matter what goes on in the startup code of the thread procedure you are kicking off, but I honestly have not payed that close attention before and can't remember ever wondering\caring....
Just came to my head right now and figured I would ask....
|
|
|
|
|
Ray Cassick wrote: I am lazy right now
I'm not in a habit of answering lazy questions, I'll keep it short: nothing is guaranteed. A managed thread is as much as "a job that could be executed independently of other jobs within the same process", which means it needs synchronization if other threads are to produce data it needs or consume data it generates, and which also means it does not even have to map onto a "physical" thread. Yes, a new Thread instance may or may not imply a new thread (at least so says the doc, I haven't ever noticed any of this).
And unmanaged threads will be scheduled by the (Windows) kernel as it sees fit, based on CPU activity, thread readiness, thread priority, some fairness measures, and the like. And particularly in Windows with a minimum of guarantees. Starting a thread is like double-clicking an EXE file: it will eventually cause something to happen.
There clearly must be a more overall question, however you forgot to ask it I'm afraid.
|
|
|
|
|
It probably gets even crazier in .Net 3 and above as managed threads are generally serviced by a central threadPool, and you just get the next one to stick up it's hand and admit to not doing any work at the moment. It will then start when it is ready. If the pool is empty the framework just extends the pool, calls a party and a whole load more threads become available... Not unlike the highfliers of the hollywood party scene.
|
|
|
|
|
Did that actually happen in 3.0? I was under the impression 3.0 and 3.5 didn't change anything to what already existed in 2.0, it just added functionality. It would be more likely to hold true since 4.0 but I haven't observed (nor tested or analyzed) these aspects, I just have known all along it was going to happen someday, as it is in MSDN doc since day 1.
|
|
|
|
|
Depends.
3.0 introduced the ThreadPool but you could still do it the same old way if you wanted. Not sure about 4.0.
|
|
|
|
|
Threads can be expected to start and threads can be expected to stop(maybe). All other assumptions are not thread safe.
|
|
|
|
|
Yeah, I figured... and honestly I am not surprised, especially now days with the progression from simple clock allocation over to physical core style allocation.
Just makes me wonder if REAL multi-threading, outside of the typical ‘I just want to be able to do a few things at a time to help increase efficiency’ is really used today except for some very time-critical systems.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
