timer

[sahel]

hi every body;
i want a method that it works like timer .i mean i want to get a
number from user in 6 second plz help me.

 

[Mike Lovell]

i want a method that it works like timer .i mean i want to get a

number from user in 6 second plz help me.

Dude, read a tutorial and use google! )

You're slamming the newsgroup.

The class is called 'Timer'. Look it up. We're like Jesus, we help those
that help themselves!

You need to do some of the work yourself, put the effort in to learn like we
all did.

 

[Arne Vajhøj]

Incidentally, personally I would strongly recommend that you do NOT
start with console applications. It's too hard to see what's going on.
Instead, use the visual designer, create a form, but three text boxes
and a button on it. Then code up an adding machine. Place a label on the
form, code a Fahrenheit to Celsius conversion, and update the label with
each intermediate step of the calculation. Single step through the
conversion with the debugger.

Console.WriteLine and Console.ReadLine is a lot easier to learn
than WinForms.

And code examples are shorter to post here as well.

Arne

 

[sahel]

Well, I'm not convinced.  Is.....

TextBox.text = "fred"

.....really any harder than this?......

Console.WriteLine("fred")

And learning how to drop a textbox on a blank form takes what - ten seconds?

Also, being honest, how many console applications get written these days?
No, I stick to my advice.


Well, that's only if you decide to post all the auto-generated form code as
well, which wouldn't normally be necessary.  Otherwise it's much the same.

SteveT

i studied a lot i didn't just send a massage & ask a question i really
search & when i didn't find that i asked u ;
but your right & after this time i will work more
thanks of all . . .

 

[Konrad Neitzel]

Hi Steve!

Well, I'm not convinced. Is.....

TextBox.text = "fred"

.....really any harder than this?......

And learning how to drop a textbox on a blank form takes what - ten
seconds?

Also, being honest, how many console applications get written these days?
No, I stick to my advice.

It is ok, that this is your opinion, but I am also thinking that a console
application is much easier for a beginner. There is simply to much stuff
that can confuse a beginner.

If someone wants to learn, then he should concentrate on it and try to
understand everything from the beginning. Why is he doing what? Having a
designer with some code that he should not touch and that maybe is not that
nice to understand. With some crappy names that maybe should be refactored
quickly, .... No, that is nothing where I want to be directly involved.
There are simply to many questions that you either explain (And that will be
quite hard in a lot of topics!) or you have to tell him to forget about that
topic.

And I do a lot of console applications when I quickly test something.
Because that is much easier than creating a windos form application. (But in
a project, when I want to test something quickly, I just add a quick
TestMethod and debug that ... I just do not want to close the solution I am
in or open another Visual Studio instance.)

But what is also important: Directly try to move forward to the target
plattform you want to develop for. If that are XNA Games: Try to create on.
If you want to develop Websites: Move forward to ASP.Net And of course:
WinForms are a good plattform, too. (But maybe presentation foundation
should be taken instead?)

But one very important point is: There is not a right and a false way.
Everyone has his favorite way to do stuff and everyone learns different. So
it can be a always good to simply try it with a WinForm and see, if that is
easier / better / whatever .... So thank you for pointing out your opinion -
even if I prefer something else!

With kind regards,

Konrad

 

[Registered User]

On Wed, 17 Mar 2010 13:44:09 +0100, "Konrad Neitzel"

- good stuff snipped -

And I do a lot of console applications when I quickly test something.
Because that is much easier than creating a windos form application. (But in
a project, when I want to test something quickly, I just add a quick
TestMethod and debug that ... I just do not want to close the solution I am
in or open another Visual Studio instance.)

Console apps are a great platform for exploring and testing both
conceptual and functional designs. There is no reason to add
unnecessary complications no matter how trivial they may be.

regards
A.G.

 

[Futu Ranon]

Also, being honest, how many console applications get written these
days? No, I stick to my advice.

Financial trading systems
Search engines
Compilers
Travel/resource/logistics planning/optimization systems
Databases
HTTP servers
Media streaming services
etc. etc.

 

[Andrew Poelstra]

Well, I'm not convinced. Is.....

TextBox.text = "fred"

.....really any harder than this?......

Console.WriteLine("fred")

Conceptually, yes. There is far more going on in the first case,
not least of which the events that are fired automatically in
TextBox when you change its value.

And learning how to drop a textbox on a blank form takes what - ten seconds?

More than that if you expect it to have a sensible location and
a use.

Also, being honest, how many console applications get written these days?

Not as many as there are applications with no user I/O whatsoever.
But GUI apps are still in the minority.

No, I stick to my advice.

I would expect so, given that you hit 'Post' after typing it.

Well, that's only if you decide to post all the auto-generated form code as
well, which wouldn't normally be necessary. Otherwise it's much the same.

Oh my.

 

[Futu Ranon]

Touche! Good examples, although I do wonder how many of each are
*actually* coded in C#, rather than *could be*.

I know of a number of proprietary trading/automated systems.

Nevertheless, you've reminded me not to make sweeping statements!
=)

I still think Sahel would be wise to try learning via Windows Forms,
too, then he can choose which approach is best for him.

I cannot find a fault with that line of reasoning.

 

[Andrew Poelstra]

Not at all. I'm always happy to change my mind in the light of a compelling
argument. In fact, I often do. On this occasion, though, my mind remains
unchanged: I found it easier to learn C# using Windows Forms, and I suggest
Sahel tries it, in case the same is true for him, too.

Fair enough, isn't it?

Absolutely - but had you changed your mind, I would have expected
you'd change your post (or mention it) before hitting send. That's
all. I didn't mean that you were inflexible.

I've never used Windows Forms (as a Linux dev Gtk or Gtk# is more
natural), so I can't comment on its ease of learning.

What? I don't understand that comment. I don't know about you, but my UI
code is separate from my "processing engine". The latter is where my work
gets done, and is the same whether I use a UI or a console. And it's the
latter where I need occasional help from forums like this.

True enough. But for people to use and test your code, the UI component
is necessary, and often the bindings between your processing engine, and
your UI, are not as clear as they would be for a simple text-based
interface.

 

[Arne Vajhøj]

Touche! Good examples, although I do wonder how many of each are
*actually* coded in C#, rather than *could be*.

LSE used (probably will use for a bit longer) a .NET based
trading system.

Lucene.NET is a search engine.

Some of the .NET tools are written in .NET (fsc.exe the F#
compiler is managed).

Arne

 

[Arne Vajhøj]

Well, I'm not convinced. Is.....

TextBox.text = "fred"

.....really any harder than this?......

Console.WriteLine("fred")

And learning how to drop a textbox on a blank form takes what - ten
seconds?

If complexity==lines then you are correct.

But it is not.

Console.ReadLine and WriteLine are understandable standalone.

WinForms require you to understand a lot of things to understand
what is going on: a complex project structure, partial classes,
events, some patterns etc..

Also, being honest, how many console applications get written these
days?

Some. And a lot of server code that are very similar to a console
app with a console.

Well, that's only if you decide to post all the auto-generated form code
as well, which wouldn't normally be necessary.

To produce a complete example some of the autogenerated stuff is
usual needed.

In incomplete examples often creates a lot of confusion.

Arne

 

[Arne Vajhøj]

Although I'm at risk of flogging this one too much, I respectfully
disagree when you are talking about learning C#. Thanks to the magic of
VS, you don't need to "understand" the UI code at all. Watch what I mean:

Create a new Windows Form project.
Drag a button and a label onto the form.
Double click the button and type:

label1.Text = "fred";

Test it.
Enhance with two text boxes and make an adding machine.

See what I mean? The bit that does the work you're interested in is the
bit you type in. The rest of it you can explore much further down the
line. You can write a reasonably complex application without ever having
to understand the auto-generated code (I've been there). Indeed, most
Windows Forms tutorials take that approach, leaving the "under the hood"
stuff until much later in the learning process.

In general I do not like the black box approach to programming.
People should learn what is happening.

And I think we have seen lots of examples of where "The bit that
does the work you're interested" is is not where the problem is.

Arne

 

[Jeff Johnson]

In general I do not like the black box approach to programming.
People should learn what is happening.

And I think we have seen lots of examples of where "The bit that
does the work you're interested" is is not where the problem is.

Yes, people should EVENTUALLY learn what's happening, but I've been pretty
much agreeing with Steve throughout this discussion. After all, there's a
lot of stuff going on behind a console application as well that is a black
box to the learner.

The bottom line is that it's a cultural thing. When I went to MVP summits in
the past with the VB.NET group (I was a VB6 MVP) I remember that the VB'ers
almost as a whole complained that Microsoft sample code was always using
console apps when virtually no VB person would ever think of doing this;
they'd just start a WinForm project and drag a text box or label onto it and
write to that. On the other hand, C#'ers (what a silly word) immediately go
for the console, probably because in the beginning most of them came from C
and were not big on the GUI.

However, C# as a language has matured and a lot of the people coming into it
now are getting it as their first language, so why shouldn't we get them
started on GUIs from the outset?

 

[Andrew Poelstra]

Yes, people should EVENTUALLY learn what's happening, but I've been pretty
much agreeing with Steve throughout this discussion. After all, there's a
lot of stuff going on behind a console application as well that is a black
box to the learner.

The bottom line is that it's a cultural thing. When I went to MVP summits in
the past with the VB.NET group (I was a VB6 MVP) I remember that the VB'ers
almost as a whole complained that Microsoft sample code was always using
console apps when virtually no VB person would ever think of doing this;
they'd just start a WinForm project and drag a text box or label onto it and
write to that. On the other hand, C#'ers (what a silly word) immediately go
for the console, probably because in the beginning most of them came from C
and were not big on the GUI.

However, C# as a language has matured and a lot of the people coming into it
now are getting it as their first language, so why shouldn't we get them
started on GUIs from the outset?

Because GUI's represent a /massive/ amount of complexity, however
well abstracted or hidden away it is. Creating a GUI without any
understanding of basic data structures, events or error handling
is a recipe for disaster.

Not to mention that ten minutes in you'll likely need multiple
threads, and then you're /really/ screwed.

And all this just to force a mouse on people who would rather
keep their hands more-or-less in one place. There's a reason
keyboards have 99 other keys to work with, y'know. It's because
two (or three, or six, or whatever) isn't enough.

 

[Jeff Johnson]

Because GUI's represent a /massive/ amount of complexity, however
well abstracted or hidden away it is. Creating a GUI without any
understanding of basic data structures, events or error handling
is a recipe for disaster.

Not to mention that ten minutes in you'll likely need multiple
threads, and then you're /really/ screwed.

And all this just to force a mouse on people who would rather
keep their hands more-or-less in one place. There's a reason
keyboards have 99 other keys to work with, y'know. It's because
two (or three, or six, or whatever) isn't enough.

I don't want to harp on the VB aspect too much in a C# group, but you have
to consider that a HUGE number of people got started in programming via
Classic VB, in which it was virtually impossible to make a console app. They
were able to handle it. (And yes, insert comment here on how many bad VB
programmers there are out there. In a way, that almost bears out my view: if
a crappy programmer can get started on a GUI, it should be no problem at all
for one with talent!)

 

[Andrew Poelstra]

I don't want to harp on the VB aspect too much in a C# group, but you have
to consider that a HUGE number of people got started in programming via
Classic VB, in which it was virtually impossible to make a console app. They
were able to handle it. (And yes, insert comment here on how many bad VB
programmers there are out there. In a way, that almost bears out my view: if
a crappy programmer can get started on a GUI, it should be no problem at all
for one with talent!)

There's a very popular view that starting with VB -causes-
people to become bad programmers. This may be part of the
reason why.

 

[Jeff Johnson]

There's a very popular view that starting with VB -causes-
people to become bad programmers. This may be part of the
reason why.

Well knock me over with a feather. I TOTALLY didn't expect ANYONE to come
back with THAT old chestnut....

 

[Andrew Poelstra]

But honestly, Andrew, it really isn't! I've been there: I give you my word
that in the early days I created plenty of Windows Form apps without the
slightest understanding of all the auto-generated code. By default it is
hidden from view, and truly, you just don't need to worry about it.
Certainly not as a learner.

If you say so. The first GUI I used was the stuff in <windows.h>
on VC++6. I had no designer to work with and pretty much nothing
was as simple as it could be.

Nowadays I use Gtk - it's a lot nicer to work with, but I still
don't use a designer to lay stuff out. It's easier to write the
code in the first place than to have to reformat and tweak it
after the fact.

(Though to be fair, for any project of reasonable complexity,
I drop the GUI entirely because I'm not able to use GUI's to
do anything reasonably complex. Maybe the problem is on my
end but it applies to all graphical interfaces.)

My point is that I'm probably not in a position to legitimately
critique this style of learning. Hence, I will agree to disagree,
and I hope you'll do the same.

Hang on, hang on. Who said anything about "forcing" a mouse on anyone? We
were simply talking about two different approaches to learning C#. I argued
(and still do) that it's worth trying both, and then choosing which works
for you. Some people (like me) find the GUI / textboxes / buttons approach
much easier.

Perhaps I went on a bit of a tangent there but my point was
that GUI's designed by people who have only ever developed using
a black-box design tool, tend to be thoroughly inaccessible to
people using a keyboard or any other non-pointing device.

I suppose this is into the realm of UI design, which is again
pretty far up the learning curse.

 

[Jeff Johnson]

Actually, we agree, there. When designing a GUI it is all to easy too
forget about people who like to drive it from the keyboard (the converse
is obviously true for console apps!)

Too true, too true. Even those who do try to add keyboard support often do
so incompletely. Be honest, thread followers: when you've had to manually
implement Cut/Copy/Paste, how many of you have handled Ctrl+X/Ctrl+C/Ctrl+V
but did NOT handle Shift+Delete/Ctrl+Insert/Shift+Insert? Even some
Microsoft apps are guilty of this. (Yes, yes, CUA shortcuts are
theoretically no longer supported, but that's a cop-out.)