|
What code?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
|
|
Hi,
1.
there is no unboxing, and no run-time penalty, if one of your methods is declared as returning IEnumerable<string> and actually returns a List<string> or a string[]. The compiler has checked each return statement returns the promised type, and they do as both List and Array are implementing IEnumerable, so all interface members are available as is.
2.
AFAIK ToList() creates a new List. IMO most ToSomeThing() methods create a new object, the one exception I know of is the meaningless string.ToString()
|
|
|
|
|
Luc Pattyn wrote: is the meaningless string.ToString()
For being meaningless it sure is used quite often 
No comment
modified 21-Nov-11 21:00pm.
|
|
|
|
|
Mark Nischalke wrote: For being meaningless I sure it used quite often
It sure is.
|
|
|
|
|
|
when a method promises to return an IEnumerable, then it can actually return a List, an Array, a StringCollection, ..., as they each implement (hence ARE) IEnumerables. IEnumerables is just a more vague description of a pretty specific object which could be a List, an Array, etc. There is no conversion, no "new object" at all.
Collin Jasnoch wrote: why not just use List<T> or arrays for your return type?
I see at least two reasons why it could make sense:
1. you want to return something that the caller can perform only some operations on; when you return a List as an IEnumerable, the caller can enumerate the items in the list, and change those items, however he can't change the list itself. That is encapsulation.
2. assuming all that is required by the caller is IEnumerable, why offer him more? As a provider of the callee, you could change your implementation (say from arrays to lists), and still return the object as an IEnumerable, the caller wouldn't notice. And sometimes, you might return either an array or a List, using different return statements in your one implementation.
Example:
Since .NET 1.0 (when no generics existed) Directory.GetFiles has been defined as returning an array, which is expensive promise: while collecting the data, they don't know yet how many items will be present, so they must count first, allocate an array, stuff it, and then return it. Had it been declared returning an IEnumerable from day one, the current implementation could have taken full advantage of a generic list.
|
|
|
|
|
|
if you need a List, it is best for the method to return a List. Turning an IEnumerable into a list afterwards is expensive.
if all you need is an IEnumerable, then it does not matter one way or the other; there is no added cost in returning a List as an IEnumerable, just as there is no added cost in passing a TextBox to a method that expects a Control.
PS: and then there also is IList ...
|
|
|
|
|
|
You're welcome.
|
|
|
|
|
As i see it the only danger is that the client actually does not have to push anything back when you return List<t>. When he add's or removes something it it, by reference, also available/removed at the providers side. For safety reasons return the IEnumerable i'd say.
Cheers, AT
Cogito ergo sum
|
|
|
|
|
|
Your resoning seems sound if you're aiming towards a distributed system or at least have a proper seperation of UI and BL. If on the other hand the UI is just another part in the same process, which may or may not be another developer. In that case you will need to be a bit more careful.
Cheers, AT
Cogito ergo sum
|
|
|
|
|
Hi, all:
Does anyone know why the HasMorePages property seems to be ignored, or more correctly, is erratic an finicky.
Either the pages all print on one sheet or loop through pages-by-the-hundred (often each one a compound page).
Assuming the problem is my own understanding, I went to my own code (where I've used it successfully in the past), and checked with the MSDN site literature. This followed by various permutations as to where in the print routine it is called. At this point, I feel as a hamster on a treadmill.
- I've done the loop inside the PrintDocument_PrintPage(...) method.
- I've taken the print loop outside, wrapping the PrintDocument->Print() call (passing a 'done' flag to control HasMorePages).
Various permutations, some of which appear to ignore the code flow when followed in the debugger.
What I'm hoping for is either a description of how the methods and properties interact that is (mentally) consistent, or a link or two referencing such explanations.
As an axillary question, what would have been so difficult about creating a New-Page method instead of this looney-tune flag?
TECH NOTES: C++ in VS2003 (== .NET 1.1 because they won't upgrade).
Thanks, in advance.
Balboos
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
According to the documentation[^] you must set the ev.HasMorePages property inside the print page event handler. Does your code follow this model?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Thanks for the reply. I deliberately didn't include the code snippets because I tried so many. Indeed, I've used it before - the event handler is the only place that ev.HasMorePages is in scope (as an arg), unless I pass it on (which, in desperation, I tried at one point). So - yes, it's in the right location.
Whilst awaiting feedback, I continue my online search and came up with what might be an explanation consistent with the observed problems:
e->HasMorePages results in another call to the printDocument handler. I can visualize this (apparently) erratic behavior as being the the result of this call. I'm going brain-dead, shortly, but know exactly what I plan to do in the AM, which can be summed up as declaring a static counter for my data loop, printing a single records worth of data to the form, and if more data is available, setting e->HasMorePages to true. Resetting the static counter only after the entire loops been handled.
Unintended recursion.
Again, though, thanks. It's good to ask about the obvious before one goes to the subtle.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I never had any problems with HasMorePages: when you call myPrintDocument.Print(), the system will fire a PrintPage event; your associated handler is where you must set PrintPageEventArgs.HasMorePages either true or false. As long as you don't set it false, the system will continue firing the PrintPage event. So you are not organizing the loop yourself, the system does it for you. You are responsible of course to provide the data that belongs to the page currently being printed, and normally the mechanism you need to achieve that is also what tells you whether more pages will be required or not.
FWIW: what I find more difficult to organize elegantly is the prediction of the number of pages the print job is going to require, this is the number you can provide to the PrintDialog in case you want to support partial page range printing. To get it right you either have to duplicate the paging logic, or somehow share it with the PrintPage handler itself.
|
|
|
|
|
Luc Pattyn wrote: As long as you don't set it false, the system will continue firing the PrintPage event
Thanks - this is the key: it's potentially recursive.
I'd just happened across a reference that said as much, which I posted. My plan is, as noted above, to use a static int as a counter (such as by giving it class scope), by which means it will (1) page and (2) not print everything on each page - or so I hope.
It's interesting that I've made this work for me in the past without understanding this simple but essential key to its use.
Thanks.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You're welcome.
And yes, you need one or more variables that live outside the PrintPage handler, so they can remember how much your printing process already has handled.
|
|
|
|
|
Not sure if this is the right place for my question. I've got my new laptop, but preloaded with Windows 7 64 bit OS. As a developer, I got a question about the use of SDKs and other stuff on my new machine. For example, when I try SQLite download, they only provide packages for "x86-win32" platforms. Does x86 32 bit stuff works well on a x86 64 bit machine? Some explannation would be much appreciated. Thanks.
Best,
Jun
|
|
|
|
|
Yes, 32-bit code will run fine on Windows 64-bit.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
At the moment, all Intel/AMD based systems that support 64-bit also support 32-bit applications; same for Windows itself. So a 32-bit app will run just fine on any 64-bit system. Mind you, an app must be 32.64 homogeneous, you can't built an app that refers to both instruction sets; and that is where some trouble may originate: if you have a 32-bit DLL somewhere (say OLEDB to connect to Access), and some 64-bit DLL from some other source, you can't combine them into a single app.
If you build apps yourself, selecting "target=x86" on a 64-bit system should provide 100% probability the app will run on all 32-bit and all 64-bit systems. Unfortunately, Visual Studio defaults to "target=AnyCPU" which makes managed code run in 64-bit mode, and that would fail to load a 32-bit DLL later on.
|
|
|
|
|
It depends (as always). Most 32-bit apps will work fine on 64-bit systems, but you may bump up against occasional problems. One example I have run into is an application called TugZip, which is a file compression utility (c.f. WinZip, 7Zip, etc.). It installs and runs fine under 64-bit Windows but none of the shell extensions work. So, if you right-click on a .zip file in the Windows explorer, then none of the TugZip options show in the pop-up menu. I have seen various work-arounds suggested such as starting Windows explorer in 32-bit mode, but it's much easier to use another tool which integrates properly. They may have fixed it by now, I'm not saying TugZip is bad, wrong, or anything like that. I'm just using it as an example of a 32-bit app which doesn't quite work on a 64-bit platform.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
