|
When i read the image it shows the incorrect output in other language not in english. here is the code for read the image..
MODI.Document modDoc = new MODI.Document();
modDoc.Create(@"h:\123.jpg");
modDoc.OCR(MODI.MiLANGUAGES.miLANG_ENGLISH, true, true);
MODI.Image img = (MODI.Image)modDoc.Images[0];
MODI.Layout layout = img.Layout;
String OCRText = layout.Text;
modDoc.Close(false);
for (int i = 0; i < lines.Length; i++)
{
textBox1.Text = textBox1.Text + lines[i];
textBox1.Text += '\n';
}
Plz anybody tell me the solution of this problem .........
|
|
|
|
|
I would like clipping a line but do not know, you can help me?
Such LiangBarsky algorithm used to cut the line is drawn by Bresenham.
|
|
|
|
|
Hello Everyone
I'm trying to create a small project in my laptop. Could someone please tell me once this application is up and running is there a possibility to access this application via bluetooth on to my mobile phone.
Please feel free to correct if my question is not at clear explonation...
Kind regards
Roni
|
|
|
|
|
Define "access"?? That's such a generic term it really has no meaning.
1. Do you want to run the application on the phone? Not going to happen.
2. Do you want something on the phone to communicate with your application? Sure. You just need to define what protocols you're going to use and what you want to transfer over this link.
3. Do you want this application to send some kind of data to the phone? Sure, see number 2.
|
|
|
|
|
Greetings.
I am currently working on a little project for fun; I am trying to have a webcam work in C#, probably by using directshow.
But I am so clueless!
I don't understand the code enough to write my own from scratch so I am seeking someone who masters C# to show Me what I need.
This would work best on MSN; ADEPofArts@gmail.com
Thank You for your help.
|
|
|
|
|
You might get a better response if you post this in this forum:
Collaboration and Beta Testing[^]
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Ah! Didn't see that one. Thanks.
|
|
|
|
|
You should also remove your email from your post so you don't get a ton of spam.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
For some reason got on a Tree class kick (tree, btree, bstree, avltree, etc). So I started porting an old MFC version I wrote 10yrs ago and decided instead to redesign it.
Concept I'm going for at this point is I'll have a base Node object, a NodeCollection and a Tree class. The btree will derive from tree, the bstree will derive from btree and the avl tree will derive from bstree.
Right now... everything looks something like:
public class Node<T>
{
public Node(T value)
{
_value = value;
}
public NodeCollection Children
{
get
{
return _children;
}
}
}
public class NodeCollection : Collection<T>
{
}
public class Tree
{
public Node Root
{
get
{
return _root;
}
set
{
_root = value;
}
}
}
Obviously, I snipped out the non important stuff for brevity, but one thing I'm not liking so far is that is that you need to do something like tree.Root.Value, tree.Root.Children[4].Value, etc to get to the real value. I.e. everything works on a Node object instead of the value object. I guess you do need a Node object so you can have somewhere to get the children from. Perhaps if I add some methods to NodeCollection to find Nodes by Value it will make it better?
Any suggestions, I'm not liking something about this design, but I'm not quite sure what it is.
My C++ version sort of hid all that by using the Windows POSITION thingy... which I guess is pretty much the same this as just returning a Node... Hmmm...
|
|
|
|
|
SledgeHammer01 wrote: Perhaps if I add some methods to NodeCollection to find Nodes by Value it will
make it better?
Hmmmm. One thought occurs to me - what happens if the value you want to return is in the root node? You'd have to check that value first, and then call the NodeCollection check. If the check is part of the Node instead, and that knows how to iterate over child nodes then that would simplify the end code somewhat (granted it would make the internal logic slightly more complex). Actually, a simple extension to this would allow you to put it into the Tree class itself, and then that would trigger the Node/NodeCollection checks - this way, the end dev only has to use something like:
var node = myTree.FindNodeByValue(myValue); Thinking this through though, there is a particular smell in place in that you actually have to supply a full copy of value that can be used in an equality test - perhaps you could extend to include an equality test as well (as a Predicate for instance), so that complex objects could be retrieved off one of their properties (useful if you want to search for a particular ID for instance).
As for the retrieving by child position, this code seems very reminiscent of manipulating XML. Again, things could be made simpler by providing methods at the Tree level which would retrieve the relevant child without having to resort to the Root node in external code. As this is all working off a Node object, you could have a method that looks something like this (completely untested, so there may be some kinks in it):
public Node<T> GetNodeByPosition(int position)
{
return this.Root.Children[position];
}The Node class could have a similar method, which would allow the dev to chain results together.
Anyway, these are just some thoughts off the top of my head - I'd really have to sit down and work through this some more.
[Edit]Not sure why your post was 1-voted. I don't see anything inherently wrong with the post.
modified 5-Jan-12 8:50am.
|
|
|
|
|
I was just a little uneasy about exposing the Node objects... but the more I think about it, maybe thats OK. In my MFC version, I was exposition a POSITION which was just a pointer to the node structure, but the node structure was hidden from the user. The user navigated through the tree by the various POSITION based methods. GetLeft(POSITION pos), GetRight(POSITION pos), GetValue(POSITION pos), etc. I guess in the C# world, just returning the Node object is considered better then trying to hide it from the user. It just seems a bit odd to me that the tree is working based on Node objects rather then the value objects. What I mean is...
if I have List<int> lst;
lst works based on ints, there is no intermediate structure hiding things.
if I have Dictionary<int, int=""> dict;
dict itself stores a KeyValuePair<int, int="">, but the way they designed it, you are usually just accessing it by dict[6] = whatever; The only time the KeyValuePair object comes into play is in the foreach loop I think.
|
|
|
|
|
Pete O'Hanlon wrote: Hmmmm. One thought occurs to me - what happens if the value you want to return
is in the root node? You'd have to check that value first
This part just made sense when I was looking over the code again  . Hmm... I wasn't thinking about having a method to find a node in the ENTIRE tree, just the current level, but then that would be funky... you'd have to write code like:
if (node.Value == blah || node.Children.FindNodeByValue(blah))
{
}
but it may not be that useful to search the entire tree because you might have a lot of items and just want to search the current branch... now I'm maybe thinking of having flags (node only, children only, all, recursive) to specifying how to search.
Pete O'Hanlon wrote: [Edit]Not sure why your post was 1-voted. I don't see anything inherently wrong
with the post.
Lol, Yeah, I stopped paying attention to votes on here. I've told Chris MANY times that the voting on here is stupid .
|
|
|
|
|
Certainly agree that whoever down-voted this post is an idiot.
I've been working with TreeViews a long time, and one question your "spec" brings to my mind is: do you define a Tree as one "root" node, from which "all springs forth," or, is a TreeView a "container" that has a "root level" collection of TreeNodes. From a classic "computer science" point of view: probably the first definition, yes. In the WinForms MS provided TreeView, and the third-party TreeView I use (a tool which makes the WinForms standard TV look, and perform, like sandpile mudspatter, imho, from Lidor Systems), the second answer would apply.
This may be a "moot" point to raise here: after all you could fill any container with a collection of "views of " TreeViews based on the "one root" model.
At my suggestion, Lidor created a dynamically updated "flat list" collection of Nodes in later versions of their TreeView, which I find quite handy, and, of course, you can write an extension to create a "flat list" of a WinForms TV (excellent examples of this based on ideas by Eric Lippert and Wes Dyer on StackOverFlow that use a stack to make creating such a flat list very efficient).
Some other stray thoughts on things I would like a TreeView able to allow:
1. the ability to declare a strongly typed TreeView: something like:
StrongTypedTreeView myStrongTV = new StrongTypedTreeView(NodeValueType: typeof(double)); 2. the ability to declare either a strongly typed 'Tag property, or a strongly typed Collection that functioned like the typical 'Tag property does now. The idea being to reduce casting of the Tag back into whatever object form you want it in.
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
I haven't written a line of C# in anger for a while but would something like this be a bit cleaner
public class Node<T> :Tree<T>
{
public T Value { get; set; }
}
public class Tree<T>
{
public List<Node<T>> Children { get; set; }
}
"You get that on the big jobs."
|
|
|
|
|
+5 Thanks, Rob: that's a very "evocative" design idea that has me headed to VS Studio right now to try it out, since it seems (to me naive brain) that architecture could be the key to a "strongly typed" TreeView.
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
Hi,
I have read the naudio sourcefiles and I don't understand how i can display a waveform befor I play the wavefile.
Does anyone can help me!
Best regards
Fred
|
|
|
|
|
Have you seen this post Waveform on the NAudio discussion boards?
"You get that on the big jobs."
|
|
|
|
|
hi
i have this coed:
private void button2_Click(object sender, EventArgs e)
{
Excel.Application APexcel = null;
Excel.Workbook MyBook = null;
try
{
APexcel = new Microsoft.Office.Interop.Excel.Application();
APexcel.Visible = false;
string[] csvFile = File.ReadAllLines(@"d:\111.csv");
MyBook = APexcel.Workbooks.Add(Type.Missing);
Worksheet mySheet = (Worksheet)MyBook.ActiveSheet;
for (int i = 0; i < csvFile.Length; i++)
{
Range r = (Range)mySheet.get_Range(mySheet.Cells[i + 1, 1], mySheet.Cells[i + 1, csvFile[i].Split(',').Length]);
((Style)r.Style).NumberFormat = "@";
r.Value2 = csvFile[i].Split(',');
}
MyBook.SaveAs("d:\\MyExcelFile.xls", Excel.XlFileFormat.xlWorkbookNormal, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Excel.XlSaveAsAccessMode.xlShared, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
MyBook.Close(Type.Missing, Type.Missing, Type.Missing);
MessageBox.Show("OK");
}
catch (Exception ex)
{
throw ex;
}
}
its work excellent but where there is hebrew letters i see gibberish
|
|
|
|
|
First, why are you splitting the .CSV file yourself?? Just have Excel open the CSV and it'll do all the parsing for you. Then you just have to save the file in Excel format.
|
|
|
|
|
can you send me any sample code for this ?
|
|
|
|
|
Really?? You can't do this:
MyBook = APexcel.Workbooks.Open(CSVfilepath);
Why does Microsoft bother writing documentation on the API's they write when only a few of us ever read it??
|
|
|
|
|
Dave Kreskowiak wrote: Why does Microsoft bother writing documentation on the API's they write when
only a few of us ever read it??
To be fair the fact that they write documentation doesn't mean that it understandable or even readable.
And finding the specific one that is meaningful and correct is often a challenge as well.
|
|
|
|
|
Given that the .NET documentation lists every method available (including Close), it's just a matter of being curious to see what's in there and reading the one line description for each method.
I find the documentation quite good for about 95% of the stuff I need. I'll say that the documentation is missing some depth in parts, but it isn't unreadable for a basic method like this.
There's even a ton of samples demonstrating all of the basics.
I'm saying most people don't even bother to look at/find the documentation let alone try to read it.
|
|
|
|
|
Dave Kreskowiak wrote: Given that the .NET documentation lists every method available (including Close), it's just a matter of being curious to see what's in there and reading the one line description for each method.
The question wasn't about a specific method of a specific class.
And as an example and in terms of your statement try to find the 'close' method that I am thinking of right now with no other context.
Dave Kreskowiak wrote: I find the documentation quite good for about 95% of the stuff I need. I'll say that the documentation is missing some depth in parts, but it isn't unreadable for a basic method like this.
I find that the documentation from multiple sources plus my decades of experience usually allows me to figure out what some method/class etc is really doing despite what the documentation says or doesn't say.
And there are times when that fails.
Dave Kreskowiak wrote: I'm saying most people don't even bother to look at/find the documentation let alone try to read it.
And I am saying the for the question originally posed that it would take me quite a bit of research to even determine what documentation to start reading in the first place.
Now if I had already used the mentioned API and used it recently then it would take less time. But I haven't.
|
|
|
|
|
If everyone read the API docs and such, how would we have fun answering questions here?
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
