|
Try this:
"SELECT * FROM myTable WHERE DateValue(date) = '" + myTime.ToShortDateString() + "'";
Parwej Ahamad
g.parwez@gmail.com
|
|
|
|
|
Dear Parwej
Thanks a lot for your help. Now it is working.
|
|
|
|
|
Hi all,
I am a new user in c# infragistic.
In c# windows application, i use ultrawintree in outlook express view style.
Now i'm trying to add new root in running time, but it don't change anything.
But if i change the view style in default style, it will add new root.
Can any one help me?
Or can any one give me the tutorial?
Many-many thanks..
|
|
|
|
|
Hi,
Many of the folks in this forum don't work with the Infragistics controls. If you don't get an answer to your question here, I suggest you post in the Infragistics forums, or look over their examples and documentation.
|
|
|
|
|
Judah Himango wrote: Many of the folks in this forum don't work with the Infragistics controls
...and with good reasons, too! They might look great, but they are horrible to program against.
|
|
|
|
|
Is that right? Interesting. I've never worked with them before.
|
|
|
|
|
Hi
the title said it.
I want to read a barcode from a USB barcode reader
into a TextBox.
how can I do that by Code?
|
|
|
|
|
I expect a hardware device to come with a driver and a manual?
if not, Google the make and model.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Most bar code readers come with a driver which can be set to emit text into the control that has the focus.
If there's no driver, you can't do anything with it.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
The barcode readers take the input just the same way as you give the input from a keyboard or a mouse. So if u have the drivers installed properly, I think it should be much trouble for u
Rocky
You can't climb up a ladder with your hands in your pockets.
|
|
|
|
|
When barcode readers read a codebar send an input as keyboard. Generally send the barcode and a final return. But it may very or be configured.
Metrologic codebar readers work in this manner
Visit my blog at http://dotnetforeveryone.blogspot.com/
|
|
|
|
|
I am writing the contents of a huge DataTable (60000 rows, 15 columns) into a text file.
Method 1: I am appending the entire content of the DataTable to a StringBuilder and then writing it to a text file in one go.
RUM TIME: 25 mins
Method 2: I am writing one row at a time to the file. ( I am still using a StringBuilder, but I am clearing the String builder after every row)
RUN TIME: 30 secs
Why this huge difference?
I have a theory, but i wouldn't want to influence your thoughts.
|
|
|
|
|
rsunilbabu wrote: Why this huge difference?
I don't know, but if I wanted to know (note: "know" does not mean "guess"), I would use a profiler to discover why.
|
|
|
|
|
IO is always faster when writing big packages instead of many small ones. I assume you use a StreamWriter to write the file. Try increasing its buffer to one megabyte (default should be one kilobyte) and method 2 should become faster.
|
|
|
|
|
Method 2 is faster....the second method took "30 seconds" only....
|
|
|
|
|
I should read more carefully. I read sec on both methods...
Theory A: You are using some kind of threading in method 1. As far as I remember StringBuilder is allergic against that.
Theory B: Physical memory gets low and thus it is swapped to hdd.
Theory C (my favourite): Every now and then the StringBuilder allocates more space. Everytime it does this it must copy the content it had before to the new memory space (like an Arraylist). This could be easily tested by giving the StringBuilder an appropriate capacity into the constructor.
Theory D: I don't have a f***ing clue
Robert
|
|
|
|
|
My theory is close to your "Theory C".
The process was slowing down as I add more and more rows. May be larger swaps?
But hard to figure out a 24 minute difference
I am still wondering about Theory A. I am doing this in a timer_elapsed event in a windows service. That may be a thread in the background!?! It may be adding to the time as well.
How the hell I am going to explain to people that the program which is was running for 25 mins now only needs 25 secs. I don't have to......but its embarrassing.
|
|
|
|
|
rsunilbabu wrote: How the hell I am going to explain to people that the program which is was running for 25 mins now only needs 25 secs.
Just tell them you are a genius but didn't want to show off with this right from the beginning...
Robert
|
|
|
|
|
Set the StringBuilders Capacity to the estimated filesize when u construct it. Or better, use the StringWriter.
|
|
|
|
|
The reason that the string builder gets slow when you put a lot of data in it, is that every time that it's capacity has to be increased, another buffer is allocated that is twice the size of the current buffer, and all the data is copied to the new buffer.
Method 3: Just write it all directly to a stream.
File output is buffered on at least two levels, so there is no reason for you to add another level of buffering. A FileStream uses a buffer so that it doesn't have to call the system for every byte written, and the system uses a buffer before writing anything to disk, as data can only be written in chunks of a cluster at a time (usually between one and eight kb). Then there is a write cache that works more or less as another buffer before the data is finally written to disk.
---
single minded; short sighted; long gone;
|
|
|
|
|
As leppie already indicated, StringBuilder.Capacity is the issue.
If you don't take care, a StringBuilder will allocate some buffer, and when it comes
to exceed its capacity, it will allocate a new buffer and copy everything.
IIRC it doubles the size every time.
The statement "use StringBuilder to speed up string operations" often does not mention
"and allocate ample capacity".
Writing smaller amounts to file is slower in theory, but using a stream should take care of
that based on its own buffering. (Warning: writing bytes one at a time would be much
slower because of the overhead involved in calling all the methods!).
So I would not doubt it a second, and write one row at a time. It simply makes no sense
to spend a lot of memory to collect things that do not need to be collected at all.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Yes. But I don't see the point in using the StringBuilder at all, just write the darn data to the file.
|
|
|
|
|
I agree an SB does not bring anything here.
I tried to explain the difference between the two proposals though.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Yes, and as long as he's clearing the StringBuilder (that's already been extended) rather than instantiating a new one each too.
|
|
|
|
|
Luc Pattyn wrote: The statement "use StringBuilder to speed up string operations" often does not mention
"and allocate ample capacity".
Probably because the StringBuilder performs pretty well even if you don't set the capacity.
25 minutes may seem a lot, but it's not that bad considering the amount of data. Based on the amount of data and the time it took for the StringBulder, some approximate calculations tells me that doing the same using string concatenation would need around 11 years to run.
---
single minded; short sighted; long gone;
|
|
|
|