|
I am still confused about your overall intentions.
I know the data is text (not memory blocks) in an existing, probably
unmodifiable, app. But then, I dont follow yet. It would help a lot
if you could sketch a more global view.
when you say " They will always be sorted from the start. No sort methods will need to be called." I understand you have code that adds a new number to
an existing, ordered, collection of numbers. Well that is exactly my point,
assume the existing collection of numbers already is range oriented
(which is true for an empty collection),
then you need to add one number at a time to such range-oriented collection,
which should not be to hard:
- locate in existing list (ur already doing that)
- if fits at end of existing range, enlarge that range
- else if fits at beginning of next existing range, enlarge that range
- else insert new range with length 1
I hope this makes sense...
Regards,
Luc Pattyn
|
|
|
|
|
Luc Pattyn wrote:
when you say " They will always be sorted from the start. No sort methods will need to be called." I understand you have code that adds a new number to
an existing, ordered, collection of numbers. Well that is exactly my point,
assume the existing collection of numbers already is range oriented
(which is true for an empty collection),
then you need to add one number at a time to such range-oriented collection,
which should not be to hard:
- locate in existing list (ur already doing that)
- if fits at end of existing range, enlarge that range
- else if fits at beginning of next existing range, enlarge that range
- else insert new range with length 1
I hope this makes sense...
I am doing that in the SelectData method. Perhaps I could email you the source code to HDPC 1.0 (my previous version of the hex editor control) and the new HDPC 2.0 (which I am just getting started on) If you wish to view the source then take a look at the Data class. The Data class is where all the complicated operations are. You will then understand what FindIndexRanges is used for if you look to see how it is used in the actual hex editor that goes with HDPC 1.0. Version 1.0 is very slow although I was attempting to keep simplicity a number one priority in version 1.0 it became a performance nightmare.
FindIndexRanges may not be needed anymore in the new version, I want to keep it for compatibility. I am still in the pre-alpha stage of development for HDPC 2.0 and somethings may be removed and changed. I may either remove the method(unlikely) or mark is as obsolete since I have new API that does not kill performance, although I cannot forsee how this control will be used if at all I want to allow as much flexibility as possible. The purpose of FindIndexRanges is to take an array of numbers, (it doesn't matter from where) and convert it to a range array. I cannot assume that those numbers ARE the selected data indexes.
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
Sure, full code could help, and I am willing to look at it,
but remember I am unfamiliar with your application domain, I do not know
what it is you want to achieve at the functional level.
Regards,
Luc Pattyn
|
|
|
|
|
There is full documentation, at least almost full for version 1.0. Is it possible to send a zip through codeproject?
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
dont know about mail thru CP, but I have mailed my e-mail adr to you.
where do I find the doc on DHPC, is there a web site or something ?
regards,
Luc Pattyn
|
|
|
|
|
Luc Pattyn wrote: where do I find the doc on DHPC, is there a web site or something ?
The source code and documentation is being emailed to you now. I have not created a web site for HDPC although I will create an article for it when it is completed or at least in beta. The documentation is in a .pdf document, class view diagrams (.png), readme.txt files, and Visio 2007 files,
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
Hi Captain,
I am under the impression your code generates way too many exceptions, and that's what
is slowing things down; optimizing with ranges wont make much of a difference as long
as Paint and MouseMove events generate one or more PointNotVisible events.
Will send you a quick hack to DataPresenterControl.cs
Regards,
Luc Pattyn
|
|
|
|
|
Luc Pattyn wrote:
I am under the impression your code generates way too many exceptions, and that's what
is slowing things down; optimizing with ranges wont make much of a difference as long
as Paint and MouseMove events generate one or more PointNotVisible events.
Yeah, it does generate too many exceptions.
The ranges are not only to improve performance of the core functionality but it is also to greatly reduce memory consumption. Selecting 1 million bytes will not use a ton of memory any more, it will use 2 longs for each selection (plus another long if you count the range variable in the Range struct).
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
Have you looked at version 2.0 yet?
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
I am getting build errors with HDPC2.0:
2 warnings in Range.cs
and 8 errors in Data.cs; first is:
Error 3 The name 'end' does not exist in the current context H:\...\HDPC\HDPC\Data.cs 235 25 HDPC
If you want me to have a look at 2.0 please provide a zip that builds.
BTW I did not recognize any of the things I looked at in 1.0, seems filenames and code
have changed drastically.
Greetings,
Luc Pattyn
|
|
|
|
|
Comment out Range[] ReturnIndexRanges(long[] indexes), that was the method I was working on when I first posted here about the treads.
Luc Pattyn wrote:
BTW I did not recognize any of the things I looked at in 1.0, seems filenames and code
have changed drastically.
Yes they have and much of it will be different. The public API will be mostly the same though with some additions and maybe slight modifications.
You are looking at the Data class which is the core of HDPC. It does not expose any methods to the programmer as it is internal. It is used by HDPC. I will email you a diagram of the architecture of version 2.0.
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
I am now looking at Data.cs in HDPC1.0 and HDPC2.0 in parallel.
Switching _selected and _changed from <int> collections to <range> collections is
definitely a big step in the right direction.
I am sure working with ranges EVRYWHERE will really speed things up.
To facilitate thiseven more, I would suggest to introduce a new class RangeCollection,
which somehow holds any number of non-overlapping ranges (maybe ordered, maybe not,
thats up to your judgement). The class would offer methods such as:
- Clear()
- AddRange(start, length) or (Range)
- RemoveRange(start, length) or (Range)
- GetEnumerator()
There would be no restrictions on AddRange; you must choose some details:
- when adjacent to an existing range, merge or not ? (may even cause a double merge)
- when overlapping, ignore the overlap or throw Exception ?
There would be no restrictions on RemoveRange (it may modify more than one of the
internally held ranges). You must choose the spec when it contains items not currently
represented in the range list (probably an Exception).
The Enumerator would return a collection of ranges that are logically equal to
what was added/removed before, without having to be identical...
In this way, the rest of your app can easily be range oriented, and the RangeCollection
class is not that difficult to create either.
If handled in this way, you may not need an "indexesArray to rangesArray" conversion at all,
or if you do (e.g. for API compatibility), its performance might be of lesser importance.
One final remark: your current Data class is not really thread-safe, and
the RangeCollection class would not be either, so it is not obvious for either of them
how to switch to a multi-threading approach (assuming you would still be
considering that at all; I dont expect it will come to that).
Regards,
Luc Pattyn
|
|
|
|
|
Luc Pattyn wrote: I would suggest to introduce a new class RangeCollection
That is a good idea. That will keep things organized at the very least.
Luc Pattyn wrote: when adjacent to an existing range, merge or not ? (may even cause a double merge)
Just as in the SelectData method ranges are joined even if they are adjacent but not overlapping.
Luc Pattyn wrote: when overlapping, ignore the overlap or throw Exception ?
When overlapping the range being overlapped may be extended or the new range being added may just be ignored as it will not be needed(if it is inside a range [.[...]....])
Luc Pattyn wrote: You must choose the spec when it contains items not currently
represented in the range list (probably an Exception).
If you remove a range that extends beyond any other range or does not even exist then it will do nothing or modify existing ranges.
Luc Pattyn wrote: If handled in this way, you may not need an "indexesArray to rangesArray" conversion at all,
or if you do (e.g. for API compatibility), its performance might be of lesser importance.
In HDPC 2.0 it wont be needed because it will be range orientated, even without the RangeCollection class available. I will keep the index - range conversions because they may be needed for some unforeseen reason. However it is unlikely I will ever use it in my own code.
Threads are beyond my knowledge for now so it will be single threaded. I'm making HDPC 2.0 capable of handling extremely large chucks of data and files. I doubt the CPU will be a bottleneck in this case. Besides thread creation creates additional overhead.
Thanks for all your help.
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
You're welcome.
I think it's time now to change the thread's title.
Luc Pattyn
|
|
|
|
|
I forgot one question: what is the source of your array ?
I mean, if there already is something that performs the task
of ordering a lot of numbers and then putting them in an array, seems like
your range-finding requirement performance-wise should be integrated with it !
I would even claim:
if you are handed a lot of numbers one by one, in random order, then
solving the overall task would work faster AND be easier than doing
it in two phases.
Furthermore, it does resemble memory recombination in a dynamic memory
manager, doesnt it ?
And if that is what it is, then there are even better ways of doing it
(taking advantage of the memory it describes !)
Luc Pattyn
|
|
|
|
|
Hey guys,
the page is wonderful, but I've got a problem with C# .NET! I wanna do some Clipboard things in a Timer, but it will not work because of the MTA Mode and I have no clue how to set it to STA Mode.
Pls help me!!!
|
|
|
|
|
Add the [STAThread] attribute above your Main method. The main method will most likely be in the static class Program inside of the Program.cs file.
namespace YourProgram
{
class Program
{
[STAThread]
static void Main()
{
}
}
}
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
Well I do recall some adventures we once had around the STA/MTA stuff.
We started of in STA (isnt that the default?) and had to switch to MTA to
achieve a sufficient level of parallellism.
So what I'm telling you is turning MTA down to STA, while solving one problem,
may introduce new problems performance wise. It just seems wrong to me that
there is such a global decision to make... or maybe I never sufficiently
understood it all in the first place.
Luc Pattyn
|
|
|
|
|
I think you didn't understand me!
My main Thread is in STA! It is like you say!
But when I start a Timer, it makes a new Thread and a new thread is not the main thread, so it is in MTA Mode and there is no way to turn it to STA!!!!
Just try this:
make a little Form with just one button, which starts with a Timer this function:
private void TimerProc()
{
Clipboard.SetText("test text");
}
It won't work, because the Timer thread is in MTA Mode and the Clipboard class need to be used in a STAThread!!!
|
|
|
|
|
new_era88 wrote: It won't work, because the Timer thread is in MTA Mode and the Clipboard class need to be used in a STAThread!!!
Are you using the
System.Threading.Timer
System.Timers.Timer or the
System.Windows.Forms.Timer?
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
Just like the title says, I use System.Timers.Timer!
The SetAppartmentState() Method exists just for Threads, but not for a Timer!
When I use a
while(true)
{
dosomething();
Thread.Sleep(1000);
}
my whole windows get stuck for a while and I don't know why!
nevertheless thanks for your help!
|
|
|
|
|
Use the System.Windows.Timer, I tried it and it works. Text gets set to the clipboard and when I get it out it is the text I put in.
Also the [STAThread] attribute is set (it is default for WinForms apps) just in case it is not currently set to that in your project.
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
Yes!!!!!!!!!!
You are my Hero!!!!
It works!!!!
Thank you and thanks to all of you who tried me to help!
|
|
|
|
|
You can create a new thread and let it sleep for a while:
Thread thd = new Thread(new ThreadStart(runTimer));<br />
<br />
thd.Start();<br />
<br />
void runTimer(){<br />
while(true) {<br />
Console.WriteLine("Timer fired");<br />
Thread.Sleep(1000);<br />
}<br />
}
You can change the threadmodel of a thread to STA, while keeping the rest in MTA model.
See this MSDN article: http://msdn2.microsoft.com/en-us/library/system.threading.thread.apartmentstate.aspx[^]
Hope this helps a bit to get you going in the right direction.
WM.
What about weapons of mass-construction?
"You can always try to smash it with a wrench to fix that. It might actually work" - WillemM
|
|
|
|
|
Yes, I remember now.
You CAN set the MTA/STA for each thread individually,
use Thread.AppartMentState on 1.1
or Thread.SetAppartMentState on 2.0
but you can set it only once for any particular thread !
Luc Pattyn
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
