|
This is the reason I always try to minimize the exit points from a method or function. The reason for the error message is that a return statement is missing at the end of the method. Put a "return false;" statement just before the last brace and your method will not have this problem.
Phil
|
|
|
|
|
By the way, Step 2 in my previous message; about verifying that the accelerometer board is communicating by using a known good terminal program is the most important step you can take.
Because if something is wrong with it or the cable, you can work for a year on your program and you will find no joy.
Joy is important!
Squeak
|
|
|
|
|
:-DI am just starting to learn C#. I would appreciate if anybody could suggest some beginners books to study. If you happen to know the author or the ISBN number that would help also. Thank you.
|
|
|
|
|
I'm also quite new to C# but I find "Programming Microsoft Visual C# 2005: The Language" by Donis Marshall (ISBN-10: 0-7356-2181-0, published by Microsoft Press) to be a pretty good reference. It isn't for the raw beginner but if you are familiar with programming and object-oriented concepts it is pretty good.
---
"No one would surrender to the Dread Pirate Westley."
|
|
|
|
|
See Richter's "CLR via C#" Second Edition. The online C# language specifications aren't a bad introduction (if you already understand OOP), and they're free. If you are dipping clear down to raw C syntax, it's not a bad idea to casually study early sources such as "The C Programming Language." But really, learning the language is the easy part. Practice requires learning the libraries -- and there isn't much help there but in library documentation.
|
|
|
|
|
I'd start with C# in Easy Steps.
Only $10, and very basic... but everybody needs to start with the basics, don't they? Gives information in a very clear form.
By Tim Anderson, ISBN 0-7607-5733-X.
(I found mine at a Barnes and Noble store.)
|
|
|
|
|
You know, for my money, the Troelsen book "Pro C# 2005 and the .NET 2.0 Platform" (ISBN 1-59059-419-3), published by Apress, is a good investment particularly if you pick things up quickly. It is a thick book but very well written.
Have fun,
Matt
|
|
|
|
|
Hi,
I have saved a DateTime object to a configuration file using the DateTime.ToString() method. I now want to read the setting and create a new DateTime object from it. How is this possible? I need both the date and time. I think I could store the day, date, month, year, hours and minutes but this seems overkill and would mean me reading many settings from my configuration file. Surely there is a better solution?
Thanks
|
|
|
|
|
Use the DateTime.TryParse or DateTime.Parse method.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|
|
If you want to store the value in a simple format, use the Ticks property to get an Int64 value. This can be used in the DateTime constructor to recreate the DateTime value exactly.
---
single minded; short sighted; long gone;
|
|
|
|
|
hey guys,
what`s the fastest way to use my C# methods within my VB6 app? I`ve done it before, but i can`t remember where exactly i found the article about how to accomplish it.
do you know any reference about the subject?
thanks in advance
cheers
|
|
|
|
|
Just reference the C# DLL in your VB App and start programming.
Brent
|
|
|
|
|
with VB6, you'll need to compile your C# as a COM object, or a completely independent app and use standard windows interprocess communications to talk between then. It's only easy if you're using VB.net since it uses the same runtime.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
Like Dan said, you have to decorate your C# component with the proper COM appointments in order to use it in VB6. COM is the only interface you have to enable your component to work with VB6. C#, or and managed code library for that matter, doesn't support the necessary exports to use simple Declare statements in your VB6 code.
Keep in mind, that when you use a .NET component in your VB6 code, you're bringing with it the entire weight of the .NET CLR. Be prepared to see your memory counters jump up considerably.
You can learn a bit more about this process in this article[^] on MSDN. The .NET code is in VB.NET, but is easily translatable to C#.
There's more in the next article[^].
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
2 questions:
1. where can I find explanations about Excel and Word namespace and how to use office classes?
2. how can I control things not inside my form like
adding the ability when clicking right click on the desktop that another function will appear in the context menu.
thanks
|
|
|
|
|
Hi everybody,
I'm building a c# application that reads data messages from an external device at a rate of 1MBit/sec.
I need to log in a window all messages.
I tried to redirect console output to a textbox, but the textbox was not fast enough to update and a half of messages were lost.
I have a thread that read continuously from the device and put messages on a buffer. A consumer thread read messages and pass them to the textbox.
So...I need a very fast logging window and, if someone will give me some suggestion to speed up .Net controls it will be great for me.
|
|
|
|
|
A textbox cannot 'lose' messages. You need to write code to cache the messages, that's where they are being lost. The textbox should just display them.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"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 )
|
|
|
|
|
Thank you Christian...
I would say that i can't add a new line to the textbox each 300-400 microsecond...
If I'm not wrong you're suggesting me to bufferize a number of messages then update text in textbox only after this number, is it?
Sorry for my bad english
|
|
|
|
|
If you can't write to the control as fast as your data stream requires, even bufferizing hasn't got a prayer of helping you. You need to revise your design to use a control that can keep up with the stream. Why you aren't writing to a console isn't clear. I hope nobody is supposed to read all this at that rate... so why the text box?
|
|
|
|
|
A list box has faster performance for adds than a textbox, but there's no UI control that can cope with a megabyte of data per second. The continual reallocation of its text container as it overflows will bring it to it's knees. When you're at 1meg and overflow, it will allocate 2 megs, and copy the old into the new. When the two meg container overflows it'll create a 4meg container and copy the existing 2 megs. Even a listbox will break well before the meg point with highspeed data. For logging mouse messages which are at most several hundred per second I was only able to cache and display 1000 messages before I began to have performance issues. Loading ~500k messages once took over a minute to complete.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
You may be able to use DirectX or OpenGL. I know it seems like overkill to use a 3D engine to display simple text, but graphics cards are built for speed. Of course, you will have to handle all aspects of the display yourself. Disclaimer: I've no clue how fast text can be written in either DirectX or OpenGL.
|
|
|
|
|
Hi,
I concur with Dan: a ListBox is a lot faster than a TextBox when large amounts of text
are involved.
But then you must be aware a Windows system is not a real-time system, under some
circumstances (garbage collection, floppy access, antivirus activated, high network
traffic, ...) it will be unable to cope with an external device producing data at a
high and uninterruptible rate. IMHO you should provide at least one of the following:
- a sufficient buffer inside the external device;
- a start/stop communication protocol;
- a retry facility
Some additional thoughts:
1. maybe you are only interested in the last N lines of information,
in that case organize the listbox in such a way that it throws away the oldest lines
when new lines come in, avoiding it to grow without limit.
2. once a control contains 100,000 lines of text it becomes practically useless: it
gets very hard to navigate, you typically dont find anything anymore.
3. you may reduce the CPU load caused by the listbox by using AddRange() instead of
Add() effectively adding say 10 lines at once; or by using SuspendLayout()/ResumeLayout()
so it gets redrawn only every say 10 lines.
4. you may improve performance (at the expense of more code) by disconnecting your data
source and the listbox: have your own buffer scheme (preferable a circular buffer)
holding the last N lines of text, which are NOT added to a listbox; and a listbox (or
a simple Panel) which acts as a low-frequency view on say a sliding windows of a fraction
of those N lines.
|
|
|
|
|
Thanks a lot to everybody!!!!
|
|
|
|
|
Hi
I am having two projects(say dll1,dll2) with the same class name,functions and everything will be same, except the logic implemented in the functions.
An exe application is having reference to one of above specified dll (say dll1), But depends on requirement, at the runtime i would be using either dll1 or dll2. say the user wants to perform different logic that is implemeted in dll2, at run time i will rename and Place the dll2 in application bin directory (with name dll1).
But the application is crashing with dll2.
Is it possible to do like this way or anyother way to achieve this requirement?
|
|
|
|
|
You may want to look at the assemblyBindings section of the config file. Possible you could use bindingRedirect to switch assemblies in the config for each application deployment.
Otherwise you will need to use Reflection to load the proper assembly and runtime.
only two letters away from being an asset
|
|
|
|