|
Hi, Richar! I can't visit Dapper. It seems that Github is blocked. Could you give me independent Dapper site ???
|
|
|
|
|
You can install the package from NuGet:
https://www.nuget.org/packages/Dapper/[^]
However, all of the documentation is on GitHub, which seems to be blocked in China.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you, Richard. I have download Dapper with Nuget Package Manager. I learn Dapper right now!
|
|
|
|
|
Hey,
I would like to discuss the value of using Unsigned value types for ensure the validy of your buissnes logic.
Just to name some exampels.
Does it make sense to let the Linq Extention 'Skip' or 'Take' be, accepting values smaller then 0? No not for me, but then why it allows this behavior by taking a int instead of an uint? Don't mention that the uint takes less memory but this is not the point.
I meant that the same space in memory can hold a bigger number ( for int ) then the signed as we got a bit more to store our data. ( sory for the vague explanation )
I Developed a network lib ( currently not OpenSource but soon ) that takes a Port. i saw that other libs are using an int at this point. This is absolute bad from my point of view. The only valid value type here is the Ushort ( 0 to 65,535 ). It does not allow a non Positiv number and limits the parameter to the buissnes logic. So why are thees value types not used that often?
modified 27-Mar-15 5:35am.
|
|
|
|
|
|
|
Jean-Pierre Bachmann wrote: Don't mention that the uint takes less memory
Um. No, it doesn't.
A uint occupies the same amount of memory as a signed int - 32 bits, or 4 bytes - and takes the same number of different values.
The difference is that it's range of values is different:
int: -2147483648 to 2147483647
uint: 0 to 4294967295
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
1) I agree (too)
2) Unsigned types are not "CLS compliant" - I guess that's the main reason. See here[^] and here[^].
|
|
|
|
|
Because it is annoying to mix int and uint. Unlike in, say, C++, you get casts everywhere. short/ushort is even more annoying. Also even if you did use them, they wouldn't really work the way you'd like them to work (ensuring the input is valid I guess), they'd just be wrong differently. If you cast an int that is accidentally -1 to an uint and give it to Take it will still be a bug. If you cast 10000000 to an ushort and pretend it's a port, it'll be a valid port but it won't be the right port. And so on.
|
|
|
|
|
Jea but this is the point, i am forced to cast my number to an ushort, and if its not possible the fault is on "your" side. I are not even able to cast your 10000000 to ushort because its not possible for that way i enforce you to validate by your self and im force you to thing about your code that that's is obviously a good thing or not? Same as Take.
ushort test;
int test2 = 10000000;
test = (ushort)test2;
will compile but cause an error at Runtime. But in your code. in that way i protect my pice of code and enforce you to do the same on your side.
|
|
|
|
|
Runs fine for me. I just get 38528.
|
|
|
|
|
Jean-Pierre Bachmann wrote: Don't mention that the uint takes less memory but this is not the point.
uint does not take less memory than a int, they have the same exact size - it changes only the representation from pure binary to 2's complement.
Integers are the basic echange unit in the system, they allow checking for overflows and underflows: if you use a ushort in a port number and have something bad that wraps around you won't get a negative number but a perfectly valid port number. If you'd have something that overflows you would still get a perfectly valid port number.
Unless you have to store/send 2 bytes values in some form of structure or have to make bit operations on 16bit wide operands there is no real need of shorts - and if you don't have to convert decimal values in 16 bits values you won't need unsigned versions of it either since math operations yields off the same binary signature. Even if you should read a decimal value and convert it in a 0-65535 range it would be better to use an int as a middle step because there may be the possibility of reading a greater number.
These are my reasons, stemmed from my experience of course.
Geek code v 3.12
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
I use 1TBS
|
|
|
|
|
Jean-Pierre Bachmann wrote: This is absolute bad from my point of view. .... So why are thees value types not used that often?
Because people are more concerned, rightfully so, in making sure that the functional logic of the software is correct versus trivial considerations.
In general it is probably 'easier' to use an integer. And your library should probably expose it as such and you should add the one statement in your code where it is exposed to do a validation check. And then move on to make sure that the rest of your library works as promised.
|
|
|
|
|
I have bound a BindingList<Produkt> to a ComboBox. When the user writes some text into the combobox, it will remove (filter out) all the entries that doesnt match what the user has entered, and then open the list showing the rest for the user to select one. The idea is that the more the user writes, the fewer options will be listed. The binding and filtering part works fine, but the problem is that when the user writes the first letter, the list opens up and autocompletes (in the text field) with the first entry of the list. Is there a way to turn this auto-completion off? I want the user to have the opportunity to keep writing OR to actively select an entry from the list.
public void Init(BindingList<Produkt> _produktLst)
{
produktLst = _produktLst;
namnCbx.DataSource = produktLst;
namnCbx.DisplayMember = "Namn";
namnCbx.ValueMember = "Namn";
}
private void namnCbx_TextChanged(object sender, EventArgs e)
{
RunFilter();
}
private void RunFilter()
{
BindingList<Produkt> filteredLst;
if (namnCbx.Text.Length == 0)
{
namnCbx.DataSource = produktLst;
}
else
{
filteredLst = new BindingList<Produkt>(produktLst.Where(delegate(Produkt p)
{
if (!p.Namn.Contains(namnCbx.Text))
return false;
else
return true;
}
).ToList());
namnCbx.DataSource = filteredLst;
if(namnCbx.Focused)
namnCbx.DroppedDown = true;
}
}
}
|
|
|
|
|
I think this question might boil down to: Can you open the list of a combobox without having one of the list entries selected, ie having something entirely different in the input field?
|
|
|
|
|
Have you thought about using the AutoComplete property on the combobox and set it to suggest?
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
Well, my idea was to not use any autocomplete, but I found this article Auto Complete ComboBox[^] where he is using it, and it works really well, just a slightly different approach. So five starts on that one.
|
|
|
|
|
Hello I am doing a project in c# and need to send pdf in email body rather than as attachment. ?? Please hemp me with some sample code. thanks
|
|
|
|
|
It doesn't quite work like that.
We do not do your work for you.
If you want someone to write your code, you have to pay - I suggest you go to Freelancer.com and ask there.
But be aware: you get what you pay for. Pay peanuts, get monkeys.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The PDF has to be an attachment. PDF's don't render in an email body.
|
|
|
|
|
I am trying to understand Async, and I have 2 examples, but I don't see the difference:
Example 1
static string sampleFile = @"C:\Projects\Sandbox\Async1\Async1\somefile.txt";
static void Main(string[] args)
{
Console.WriteLine("Task 1 started");
Task task = new Task(ReadTheFile);
task.Start();
task.Wait();
Console.WriteLine("The READ task was started");
Console.ReadLine();
}
static void ReadTheFile()
{
int count = 0;
using (StreamReader reader = new StreamReader(sampleFile))
{
Console.WriteLine("Reading the file XXXX.");
string v = reader.ReadToEnd();
count += v.Length;
}
Console.WriteLine("Count: " + count);
}
Example 2
static void Main(string[] args)
{
Console.WriteLine("Task 1 started");
Task task = new Task(ProcessDataAsync);
task.Start();
task.Wait();
Console.WriteLine("The READ task was started");
Console.ReadLine();
}
static async void ProcessDataAsync()
{
Task<int> task = HandleFileAsync(sampleFile);
Console.WriteLine("Getting ready to read the file.");
int x = await task;
Console.WriteLine("Count: " + x);
}
static async Task<int> HandleFileAsync(string file)
{
Console.WriteLine("HandleFile enter");
int count = 0;
using (StreamReader reader = new StreamReader(file))
{
Console.WriteLine("Reading the file.");
string v = await reader.ReadToEndAsync();
count += v.Length;
}
Console.WriteLine("HandleFile exit");
return count;
}
They both read in a text file with 1,000,000 lines. The first one actually seems faster.
What is the real difference here?
Thanks
|
|
|
|
|
Your main problem is in thinking that async is faster. The thing that takes the time is reading the file and both examples do that. The only difference is that in the second example the thread is freed up to other things while it waits for the task to complete. You're only going to see any benefit in doing this if your system is under a lot of load and doing a lot of heavy tasks. Further more, how much benefit you see with asynch processing depends on how many cores etc the machine has. While the asynch tasks may free up your threads, that comes at a cost too so it depends on if the benefit if the asynch code outweights the extra cost. So in your example running a single time you're getting no benefit from the asynch calls, but you're getting the overhead involved in the thread switching about.
If you want to time your code to see if there are any benefits to one thing over another then you can use the System.Diagnostics.Stopwatch class.
|
|
|
|
|
Your second example is not the correct way to use async . You should avoid async void wherever possible:
Avoid async void methods[^]
You might also get better performance if you use an asynchronous Stream to read the file.
Try this:
static void Main(string[] args)
{
Console.WriteLine("Task 1 started");
Task task = ProcessDataAsync();
task.Wait();
Console.WriteLine("The READ task was started");
Console.ReadLine();
}
static async Task ProcessDataAsync()
{
Task<int> task = HandleFileAsync(sampleFile);
Console.WriteLine("Getting ready to read the file.");
int x = await task;
Console.WriteLine("Count: " + x);
}
static async Task<int> HandleFileAsync(string file)
{
Console.WriteLine("HandleFile enter");
int count = 0;
using (Stream stream = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, FileOptions.Asynchronous))
using (StreamReader reader = new StreamReader(stream))
{
Console.WriteLine("Reading the file.");
string v = await reader.ReadToEndAsync();
count += v.Length;
}
Console.WriteLine("HandleFile exit");
return count;
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
An array of what?
The whole point of a DataTable is that it takes a mixture of column datatypes: as does Excel. So if you want to read Excel Data into an Array, you probably need to create a class to hold each row, with properties for each column.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|