Do you just need code to generate the strings in that sequence or do you need conversion to/from int?
The implementations likely will be quite different depending on the answer.
(Code based on the code you've posted assumes all you need is the strings in sequence. And never needing to start mid-sequence!)
It could be that is what Angela (OP) wants, however what is shown is that after Z9999 is AA000. I.e., as the length of the alpha part of the string gets longer, the numeric part gets shorter. The total string length remains 5.
Hi guys. StreamWriter.WriteAsync exists in 4.5 but not 4.0. I'm getting a sporadic error- out of memory exception, when I use StreamWriter.Write(String Builder). I'm not sure if I can move up to 4.5 yet, what's a good work around for 4.0?
How big is that freaking StringBuilder?? If you don't specify a size, it starts with 16 characters and allocates a new array internally every time you exceed it's capacity. So, it starts with 16, then goes to 32, 64, 128, 512, 1024, ... when you get into VERY large objects, you can be allocating megabytes of memory and possibly hit a size where the CLR doesn't have a big enough contiguous block of memory to fit the new size.
This also applies when you finally call .ToString on the StringBuilder. A new String object has to be allocated and the data in the StringBuilder copied to it. Again, if sufficiently big, the new String may not fit in memory because of a fragmented large object heap.
The CLR will allocate any object requiring more than 85K (IIRC) out of the LOB. The LOB isn't compacted and defragmented like the Smaller Object Heap is. So if you're allocating and freeing a bunch of large objects, you could be fragmenting the LOB to the point where you can't allocate a new object of the size you need, even though there's enough TOTAL free memory.
But, the way around this little problem using StringBuilder is to allocate the StringBuilder with a size sufficient to hold the entire POSSIBLE string without having it constantly reallocate itself.
Oh! And as for the StreamWriter.WriteAsync, there is no equivilent in any other version of .NET. You'd have to implement an Async version yourself. But, I don't think that has anything to do with your problem right now.
I want to ask something about radio buttons in a web page. I'm using c#.net.
Let's assume that I have a table with 5 rows and 3 columns. I put a radiobutton in each cell of this table. So we have 15 radio buttons.
The user should select exactly one choice in each column, and at most one choice in each row.
I tried radiobuttonlist in each row. But in this case the user can select more than one choice in a column. Or the user can not give up a selection in a row.
I think that I need to write a client-side script. But I could not figure out this problem in a practical way. I wish I had a control that solves this problem.
The radiobutton list in each row seems like a good approach because it handles one of your constraints: at most one choice in each row.
To handle the other constraint (exactly one choice in each column) you need to make a handler that's called whenever the selection state of a radio button changes, then check this constraint in the handler. If it's violated (i.e. more than one choice in a column) you can give the user an error message or change their previous selection in that column.
When they're done (e.g. they press the OK button), then you can check to see if every column has a selection.
hey guys !
can you guide me ,how can i write code in good ways!?
well lemme explain whats my problem !
i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style !
as you know for one porpuse is many way to achieve ! but i found always choose worst way !
well is any book or reference to teach me how i choose best way? at least better way!
Bugs tend to appear in unclear code. They're harder to find there too. Maintenance of unclear code is more expensive. Unclear code is unreliable.
Try to make your methods short. As a method grows in size, its complexity increases faster than linear. If a method is becoming too large, break it up into 3-5 subroutine calls.
Start with designing the GUI. This will guide the rest of the development.
Don't feel bad if the approach you took was the worst one, because you'll learn from this experience. All programmers go through this. Try to summarize what you've learned in a simple rule you can follow to avoid this problem in the future.
Algorithm selection is a more complex topic. A course (or book) on data structures will also cover the most common algorithms used on these structures. These are also graduate courses specifically on algorithms.
(If you haven't already studied data structures, you should. It's one of the more important areas that you'll use on all but the most trivial programs.)
I always start with the data model design. I've found that starting with the GUI tends to influence bad practices in the data model or breaks even breaks it to the point where you need to toss it out and start from scratch.
There are many approaches and many problem types. There's no one correct approach for all problems, and each individual has their own style.
In each approach (GUI first or data model first), you can make discoveries that invalidate your previous design. Experience lets you anticipate more accurately the needs of the other half, while designing the first half.
In this case, I was answering a beginner's question. This person is unlikely to be dealing with a complex data model, and the needs of the GUI would probably be clearer, and would point the direction to go with the data model to support the GUI.
In my biased opinion, the primary purpose of an application is to satisfy the users' needs as well as possible, and letting the data-structure decisions steer you into a less-optimal GUI detracts from this.