|
Strikeout is read only so you cannot modify it on the fly. Instead create a new font and place it in DataGridViewCellStyle.Font. Something like (I'm not near VisualStudio right now so this may contain several typos):
dgr.DefaultCellStyle.Font = new Font(dgr.DefaultCellStyle.Font, FontStyle.Strikeout);
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
I had a go at this, but couldnt quite get it to work, and I've ran out of time. I'll spend a bit more time on it tomorrow.
It looks like the right lines. I'll give it more attention in the morning and let you know.
Thanks very much for your time on this. 
|
|
|
|
|
No problem 
If you get stuck tomorrow, send a post on this and let's see if we can help.
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
Hi
Just to let let you know, you got me on the right lines.
The exact code I used was:
dgr.DefaultCellStyle.Font = new Font(new FontFamily("Microsoft Sans Serif"), 8.25F, FontStyle.Strikeout);
Thank you again for your help.
|
|
|
|
|
You're welcome
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
Hi there
Let's say I have a txt file with 100.000 words which I'll load into memory. I need to manage this file as a database in order to provide a character prediction application. What method can I use in order to have a fast response, even on embedded devices?
|
|
|
|
|
Speed of search comes through complexity of code. The more indexes you build, the faster it will be, but the more memory it will use.
Christian Graus
Driven to the arms of OSX by Vista.
"Iam doing the browsing center project in vb.net using c# coding" - this is why I don't answer questions much anymore. Oh, and Microsoft doesn't want me to.
|
|
|
|
|
Don't load it into memory. Use a file stream and appropriate indexes and it will be fast as the size of the file increases close to and beyond the amount of available ram for the application, especially on embedded devices.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
One possibility is to use even SQL Server compact edition and with a constantly open connection query potential words from db. This would ease the index building.
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
Here's a suggestion.
Assuming the file is sorted so the words are in alphabetic order you can treat it as an array of words and use the Seek method to do a binary search.
There are a few caveats e.g. I think you need to use a BufferedStream and it might mean padding words with trailing spaces so you can calculate the offset.
Just a thought - perhaps not completely practical.
|
|
|
|
|
One way to do this would be to split the words up into smaller chunks, and then have *pointers* to keep them together. Consider this small file:
Adrian
Andrea
Andrew
Anthony
Brian
Charles
William
Winston
This could be tokenised like this:
Ad ri an
An dr ea
ew
th on y
Br ia n
Ch ar le s
Wi ll ia m
ns to n
As you can see, the list of choices narrows quite dramatically, the further on you get, and the information becomes quite easy to traverse. In this example, the user types in A and gets a choice of 4 entries. As soon as they press n, it breaks down to 3. Pressing d narrows it down to 2, and they keep going until they get to the end (or choose one out of your selection).
The downside to this approach, is the actual splitting of the words is the time consuming part of the process, but if your solution allows you to preparse them into smaller units up front, the results can be quite dramatic.
|
|
|
|
|
that's a great answer dude!
|
|
|
|
|
Read it and slap it in a tree structure so you can traverse quickly thru the possibilities.
|
|
|
|
|
Try SqlLite[^]- a file system based SQL database engine. Then use normal SQL queries to fetch the required data. It would be much faster.
|
|
|
|
|
A database has a lot of overhead, which you can avoid with your own data structure. I suggest a tree structure where each level takes you one letter farther in the word:
The root will have 26 sons, for the 26 possible first letters. Each of these sons will have up to 26 sons (grandsons of the root) for the (up to) 26 possible second letters, and so on.
1. It saves space because all words sharing a common prefix will use the same path from the root, giving you some compression.
2. It's faster than a database because you don't have to do any time-consuming queries; at each node you have a list of all the possible next characters.
3. When building this tree from your word list, you can increment a counter for each letter added at the current node. This will give you the frequencies for each continuation letter. You can then use these frequencies to predict the most likely continuation.
|
|
|
|
|
here is the first part of an XML file I am trying to parse.
<?xml version="1.0" encoding="utf-16" ?>
- <GPO xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.microsoft.com/GroupPolicy/Settings">
- <Identifier>
<Identifier xmlns="http://www.microsoft.com/GroupPolicy/Types">{89AEAFFE-E1F8-4786--6BE2D991625E}</Identifier>
<Domain xmlns="http://www.microsoft.com/GroupPolicy/Types">FQDN of Domain</Domain>
</Identifier>
<Name>Citrix_policy</Name>
<CreatedTime>2008-03-06T23:08:05</CreatedTime>
<ModifiedTime>2008-08-27T20:49:49</ModifiedTime>
<ReadTime>2008-10-24T01:29:41.40625Z</ReadTime>
.....
</GPO>
I am trying to use XPathNavigator but the following code returns the whole xml document
XPathDocument document = new XPathDocument(stream);
XPathNavigator nav = document.CreateNavigator();
XPathNodeIterator node = nav.Select("/GPO/Identifier/Identifier");
string test = node.Current.InnerXml.ToString();
MessageBox.Show(test);
What am I doing wrong?
|
|
|
|
|
Try to use MoveNext method on XPathNavigator after calling Select. Also if you have simple queries, you can use directly SelectNodes for XmlDocument.
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
Thanks for pointing me in the right direction, i have figured out how to do a simple query with Xpath, now the next step...
I have a large xml doc that i am parsing it has 2 big sections they have their own nodes in the doc. what will tell me when I have reached the end of the node? so I can kill my loop.
Thanks
|
|
|
|
|
If you're using XPathNodeIterator.MoveNext, it will return false when no more nodes are found.
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
a while loop will read through the whole doc
while(nodesText.MoveNext())
{
// code here
}
here is an example of the XML layout
<root>
<info>
...
<settings>
...
<adv settings="">
...
br mode="hold" />
I need to be able to tell when I reach the end of each node (info, Settings, adv settings...) so I can exit my loop, everything I have tried so far either reads the whole doc and returns the text values or get static path text. if I can find a way to use Xpath to start each loop (I can do this) but not sure how to get the loop to stop where I want it to stop.
hope this makes sense....
|
|
|
|
|
Can you post an example xml doc and your code. I'll try to reproduce the problem.
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
i will send it to you once I can clean the XML file of all confidential data.
thanks for your help
|
|
|
|
|
No problem 
However, I must go and get some sleep so I'll check on this thread tomorrow again.
If possible, use just a small portion of the xml doc. Basically I believe that we need just a node (at correct level) with few (similar) descendants to find out the problem.
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
Hi,
I'm working on a solution to boost Log4Net performance in our ASP.Net web applications. I have found many posts about using Log4Net's "AsyncAppender". I made a sample web application to test this solution, but my test results shows that the log methods take double time to execute when I use the AsyncAppender.
Log4Net.config:
<br />
<appender name="AsyncAppender" <br />
type="SampleWebApplication.Appender.AsyncAppender, SampleWebApplication"><br />
<br />
<appender-ref ref="RollingLogFileAppender"/><br />
<!-- <appender-ref ref="AsyncAppender"/> --><br />
</appender><br />
<br />
<root><br />
<level value="ALL"/><br />
<appender-ref ref="RollingLogFileAppender"/><br />
</root><br />
<br />
C# Code:
<br />
Stopwatch objTimer = null;<br />
objTimer.Reset();<br />
objTimer.Start();<br />
<br />
for (int n = 0; n <= 10000; n++)<br />
{<br />
log.Debug("This is a debug message");<br />
}<br />
<br />
objTimer.Stop();<br />
Console.WriteLine("Log Ticks :{0}", objTimer.ElapsedTicks);<br />
Results:
Using "RollingLogFileAppender":
29,187,893,440 (ticks)-->9,122 (milisecond)
28,473,901,664 (ticks)-->8,898 (milisecond)
28,302,560,368 (ticks)-->8,845 (milisecond)
28,439,245,696 (ticks)-->8,888 (milisecond)
Using "AsyncAppender":
56,301,661,280 (ticks)-->17,595 (milisecond)
55,775,842,640 (ticks)-->17,431 (milisecond)
56,351,447,984 (ticks)-->17,611 (milisecond)
I'm using VS.Net 2008 and .Net 3.5 for this application.
Do you have any idea about this problem? Is there any other solution to call log methods asynchronously?
Regards,
Farzad Badili
|
|
|
|
|
10000 log messages in 10000 milliseconds. That's a thousand log messages per second. I would suggest that if this is causing you performance problems when you are writing too many log entries.
Try looking at where/when you are writing to the log and decide if it's actually beneficial to log data at this point. Surely your just going to be generating so much data you'll never actually be able to analyse it all.
Simon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
