|
I wasnt sure how to phrase the question in the subject, but I am writing a program for work that will do fill calculations for conduit.
I need a way to store wire sizes with the corresponding name of the wire, so that its easy to retrieve, edit or update within the program.
I was thinking of using the Settings.settings, but is that the best way/ method to use?
Suggestions?
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
It sort of depends on how many different types there are, and whether you need any other information stored with them. A simple JSON or XML file would work for a reasonable sized sample. Both types are fairly easy to manage in .NET.
|
|
|
|
|
I am storing wire types and their outer dia. size.
2 THHN/THWN & its OD of .378
8 THHN/THWN & its OD of .213
10 THHN/THWN & its OD of .161
and so forth. I would be search for the wire type name to get to the OD for the calculations.
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
I think my suggestions still hold; XML and JSON are common standards so are better than creating your own file format. The only downside is that you need to read all he records into a List<t> before you begin. And unless you have thousands (or even just hundreds) of records then a database is probably overkill.
|
|
|
|
|
If you have it available, an SQL Database is a good approach, because it's easy to share among multiple users and multiple apps - and "basic information" like product / part descriptions have a tendency to grow and get used for other things.
Storing it in a DB means it becomes more readily available company wide, and can thus be used for mreo things.
It really depends on what you are doing, but generally settings is a poor place to keep "general" information - app specific data like where to display it, who logged in last, what colours they prefer, that sort of thing is fine, but once you start with actual data it gets unwieldy.
And while JSON / XML as suggested by Richard are fine, they can get problematic quickly, if they have two or more users / apps processing the same data. Not saying they are bad - I use JSON a fail amount - but I find that they are better for sending "one-time" information rather than as a "updatable" store.
There is also the fun of deciding where to store them: since production software is normally installed in the Program Files folder that can cause problems since it's generally write protected for anti-virus reasons. With a "proper database" the server takes care of that and allows the data to the shared and if necessary updated by multiple sources.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Odds are, unless it's "lots of data" that changes a lot, you're better off creating internal lists and dictionaries; defining them as static; and loading them in static constructors.
At the very least, you'll need a "data repository" in memory, so you should prototype that in code with small sample data instead of sweating input files / databases early on.
It's easier to change your "code model" first, instead of any file / database model; assuming you even need a settings / database file.
In fact, a "database model" can be generated from your "code model" once you have that figured out; if needed, using Entity Framework and SQLite, say. ("Pro" marketing)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Using Settings would be fine if it's just a handful of wire sizes, but it gets unwieldy pretty fast. Settings is better for recording who logged in last or the last position of a form.
If the number of wire sizes is fairly small (like under 100) and not subject to change, it might be simpler to just enter them into a static dictionary or list. This is especially true if your application doesn't already use a database. In the case of Settings, the key has to be hardcoded, (e.g. Properties.Settings.Default.Wire14Size), but with a dictionary, the key can be a string.
This is from an application that reads PDFs. It can tell the measurements of each page, but how to display the common page-size name?
var paperSizes = new Dictionary<PointF, string>
{
[new PointF(LTRW, LTRH)] = "Letter Port",
[new PointF(LTRH, LTRW)] = "Letter Land",
[new PointF(LEGW, LEGH)] = "Legal Port",
[new PointF(LEGH, LEGW)] = "Legal Land",
[new PointF(TBLW, TBLH)] = "Tabloid Port",
[new PointF(TBLH, TBLW)] = "Tabloid Land"
};Then, somewhere else, some we have a page
PointF thisPage = new PointF(somePage.Width, somePage.Height); To determine the name of size of that page, we do this
if (paperSizes.ContainsKey(thisPage))
{
return paperSizes[thisPage];
}If you need to find out the size of something based on its name, just make the name the key in the dictionary.
|
|
|
|
|
The minute you say more than 1 user can see the data OR the number if wire type/size will need to be added to you will be better serve by implementing a database server (unless you are a VERY small company you probably have one already)
Once you move to a database served solution it open up a myriad of opportunities. Storing calculation results may be a simple one.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Richard A Knox wrote: I need a way to store wire sizes with the corresponding name of the wire, so that its easy to retrieve, edit or update within the program.
1. Where does the data come from in the first place. And how is that source managed right now.
2. How many exactly will there be. 10? 1000? 100,000?
3. How often do they change?
-----------------------------------
So if the above is
1/2. 10. Doesn't actually matter where they come from.
3. With 10 it will be not very often.
Solution: As suggested hard code it.
-----------------------------------
1. it is in a spreadsheet
2. There are more than 50,000
3. They add them weekly.
Solution: You will need a database. Either traditional relational or an object store.
You can create code that extracts if from the spreadsheet but I suspect that is just more work than is needed. For the first load dump the spread sheet to a file and then use a tool to load the entries into the appropriate table. That is probably easier (in some sense) using a traditional relational database.
You would also need a UI to search, update, delete, add entries and you would need to convince the people that do this now to use this instead of the spread sheet. Otherwise you will need to complicate the above process by loading the data on a scheduled basis from the spreadsheet (same process as above.)
|
|
|
|
|
Hy friends i have the fallow code
In the marked place with ** I need a a close command for the generated form!!!!
Visible=false and this.close(); NOT WORK
HELP ME PLS!!!
THX
PROGRAM CODE SCHAME
FORM 1 WITH BUTTON1 =>WHEN I click to button 1 =>generate a new form and button
When I click to close button in then new form i like to close the new form and let just the first form
open
Form 1 Button 1
{
Form tmpform = new Form(); /*TEMPORARY FORM CODE*/
tmpform.StartPosition = FormStartPosition.CenterScreen;
tmpform.Size = new Size(968, 480);
tmpform.Text = "Cyberdesk-Nagyitó";
tmpform.MaximizeBox = false;
tmpform.Show(); /*TEMPORARY FORM CODE*/
TextBox tempbox = new TextBox(); /*TEMPORARY TEXTBOX CODE*/
tempbox.Text = Box_Ugy.Text;
tempbox.Multiline = true;
tempbox.Location = new Point(3, 3);
tempbox.Size = new Size(920, 400);
tempbox.Font = new Font("Calibri", 12);
tempbox.ForeColor = Color.Black;
tempbox.Padding = new Padding(6);
tmpform.Controls.Add(tempbox); /* /*TEMPORARY TEXTBOX CODE*/
Visible = false;
/*TEMPORARY BUTTT*/
Button gergo = new Button();
tmpform.Controls.Add(gergo);
gergo.Text = "Back";
tmpform.Controls.Add(gergo);
gergo.Location = new Point(6, 407);
gergo.Size = new Size(75, 23);
gergo.Show();
InitializeComponent();
gergo.Click += gergo_Click;
tmpform.Controls.Add(gergo);
}
private void gergo_Click(object sender, EventArgs e)
{
********===========>Here i need a form.close()
FO_FRegister firmr = new FO_FRegister();
firmr.Show();
|
|
|
|
|
Member 15512677 wrote: Visible = false;
whose visibility would that be?
Luc Pattyn [My Articles]
The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
|
|
|
|
|
I don't know if this helps, but you know that form.Show() doesn't display the form and wait for you to interact with it? Try using form.ShowDialog().
|
|
|
|
|
The problem is that Close will do just that: close the form - and since Form1 is almost certainly the "startup form" when it closes the system automatically closes the application which closes all forms and exits completely.
I'm just guessing here but it looks like you have a login screen or similar which you want to display, then close and remove when the user logs in. That isn't the way I'd do it - particularly since your current code appears to be adding controls and handlers to a different form, which is a bad idea.
Instead, make your "main display" the startup form, and in the Load event use ShowDialog to display the login form. When that exits, the code will continue from that point and you can add your controls to the current form if the login succeeded.
That way, forms don't need to "know" what each other is doing, and closing the main form terminates the app so you don't have to hassle with it!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I am working with EPPlus which generate excel file. now i have to hide range of columns. this code i used to hide range of columns in one go.
var rangecol = ws.Cells["M1:P1"];
var hiddenColumns = rangecol
.Select(cell => cell.Start.Column)
.Distinct()
.Select(rangecol.Worksheet.Column)
.ToList();
foreach (var column in hiddenColumns)
{
column.Hidden = true;
}
the above code is working and hiding columns but if there are 4 columns in range then it is hiding 4 columns individually not hide in one block. i want 4 columns should be hide in one block instead of 4 blocks.
please tell me what mistake is there in my code for which groups of columns are not getting hidden in one block. Thanks
|
|
|
|
|
What do you mean by "hidden in one block"? As far as I can see, at least in Microsoft Excel, there is no behavioural difference a sheet with four adjacent columns hidden one-by-one and a sheet where the four columns were selected and all four were hidden at the same time.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In VBA it would be (for the columns from D to F):
Columns("D:F").Select
Selection.EntireColumn.Hidden = True
Try to find something similar in C#
|
|
|
|
|
... I Introduction
Imagine you have bright young student sitting down with you, whom you've introduced to Linq, and generics ... and, they've had no problems mastering 'Select and 'Where, 'Aggregate, etc.
You have introduced them to the use of 'yield return' in a method to return an IEnumerable they can turn into an instance of a collection. They "get that," and get use of yield means they can skip direct assignment to a pre-defined, initialized collection, or, a collection instance reference passed in as an 'out parameter.
And you are trying to explain to them the "deferred iteration/evaluation" aspect of IEnumerable, and the way that enables some advanced practices (function chaining).
At that point, you can sense the student is hesitant; you ask her/him what's really on their minds, and, because they trust you, they tell you. They ask interesting questions like:
Is there any real reason to use an IEnumerable ?
What's so useful about deferred evaluation ?
Isn't deferred evaluation dangerous because you have no idea of what might have changed in the time between assembling the IEnumerable and iterating/evaluating it ?
Why can't I test an IEnumerable to see if it's empty, or null; why do I have to trigger iteration with 'Count() to see how many items it has, and, why can I only use 'Any to see if there are no items in it without triggering iteration..
... II Context
I speak of an IEnumerable<T> returned from a Function (C# Func) that is ready be iterated over (has items).
I've had some interesting exchanges with my esteemed colleagues @RichardDeeming and @HaroldAptroot on this subject in this recent thread, here: [^].
I won't recapitulate that thread here, both because I'd like to hear your initial responses, and, I don't want to, possibly, misrepresent Richard or Harold's views.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 22-Jan-22 15:52pm.
|
|
|
|
|
So in terms of teaching...
BillWoodruff wrote: What's so useful about deferred evaluation ?
The data returned is in memory.
Your computer has 32 gig of memory (or whatever it is.)
The IEnumerable returns 32 gig number of entries.
Where does it fit into memory if you did it all at once?
(Of course not saying that would be a good idea, but rather as a thought experiment.)
BillWoodruff wrote: Why can't I test an IEnumerable to see if it's empty, or null; why do I have to trigger iteration with 'Count() to see how many items it has, and, why can I only use 'Any to see if there are no items in it without triggering iteration..
The interface can only do what the interface does. This specific interface is very old and was only designed, very likely, with in memory arrays/lists in mind. Enhancing it now would break everything.
Might want to mention there are other ways to do it that would allow one to do that even for large sets (so not bringing everything into memory.) But also mention that using linq to process large sets in memory is going to be a problem regardless.
BillWoodruff wrote: Isn't deferred evaluation dangerous because you have no idea of what might have changed in the time between assembling the IEnumerable and iterating/evaluating it ?
What if you have the set in memory and the source changes between when you use it and then? How is that not the same problem? There is no such thing as absolute anything in the universe including time. So understand the problem and define the rules to deal with the differences that will occur. Example is ordering something online but while you are ordering something else the first item gets all used up by other people's orders. So when you finally go to pay it tells you it out of stock. When you started it was there but by the time it was needed it was gone.
|
|
|
|
|
jschell wrote: This specific interface is very old
The original non-generic version is based on COM's IEnumVARIANT[^], so it's practically prehistoric. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Upvoted for responding with some substance to a lonely thread.
Thanks, mixed in with your howling tautologies, is the implication you can trigger partial iteration to handle more memory than is available ... if there's a cheap way to use virtual memory with IEnumerable, I am all ears.
fyi: detailed history of generics in .NET: [^].
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
BillWoodruff wrote: if there's a cheap way to use virtual memory with IEnumerable
Large data sets still end up going to disk since "virtual memory" in the traditional sense uses the disk to get that memory.
That is why for example even though a binary sort might "seem" fast if you attempt it on a large data set that requires disk paging it not going to work. See heap sort instead.
Actions on large data sets which involve disk access always require careful design. They can't be fixed by implementation (where implementation precludes design.)
So for example that is why one must carefully consider what indexes database tables should use.
And if one is going to return a sorted list to a UI which originates from a database then from the very first design the API should have paging in it. I have seen silly designs for decades (now and then) where the UI falls over because the developer designed a UI report and tested it for 20 entries and now the major customer using it has 20 million entries. And the UI was set up to sort it in memory.
As for IEnumerable you can of course back it with anything. So for example the implementation can use a database paged query. The call to the exposed methods track the point where the last chunk was grabbed in the database and it returns the next chunk and then feeds from a chunk until that one is empty. That doesn't fix the count problem because there is no way to expose the count in the first place. So you would need to use another interface. You can of course use a double interface and then in the calling code it would need to cast to get the top level which has a count. The backing implementation would then provide the count in a better way than using the IEnumerable iterator.
But of course there are often other design problems with solutions like the above.
1. They assume that the count is a absolute. With large datasets the data very likely will be in transition. By the time you get to the end there could be more or less than the original count.
2. They right UIs with expectation that users are stupid and don't know how to do their job. So that example above with 20 entries and no other way to search becomes absolutely useless when there are 20 million entries even if it is paged. It should always have search criteria.
|
|
|
|
|
Me: "You know how when you have two cans connected with a string and when you pull the string tight you can hear what someone says in the can at the other end of the string?"
Student: "Yeah"
Me: "Well it's not like that at all."
I think humor should be injected into every conversation...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Is there any real reason to use an IEnumerable ?
Yes; first off IEnumerable was Microsoft implementation of functional programming algebras for a List. It is essentially a monadic data type that encapsulates List; monadic data types are typically designed to conform to a fairly standard set of functional algebras i.e. providing a common API for computations.
One major difference with Microsoft’s implementation; is that Microsoft decided to depart from the more familiar naming conventions used in functional programming circles, for example:
- Select is more common referred to as a Functor; and its method is more typically named Map.
- SelectMany is more commonly referred to as a Monad, and its method is more typically named FlatMap.
Microsoft's choice was to align their monadic implementation with SQL for obvious reasons; they had an existing group of programmers who would be already quite accustomed to SQL; so adopting that style of API would simplify adoption.
Category Theory
Function programming algebras are directly tied to Category Theory; hence there are specific tests (axioms) that can be performed to verify that these common computations conform to the axioms of a Functor; for example, it must preserve:
- Identity morphisms
- Commutativity re composition of morphisms
Similarly said there are rules governing the other algebras like SelectMany; which as I mentioned is a monad, etc…
The benefit of IEnumerable is the same as for any other functionally conforming type; it allows the use of a common set of algebras (common API) on the type that is encapsulated by IEnumerable. In Functional Programming; IEnumerable is not the only monadic data types that are used; there are also for example:
- Identity Monad; this is the most trivial of the monadic types; encapsulating a single value.
- Maybe Monad; a type that encapsulates an optional value; similar to the Option type in C#
- List Monad; a type that encapsulates a list of values; similar to IEnumerable type in C#
- Either Monad; a type that encapsulates a value with one of two possible outcomes.
- Validate Monad; a type like Either that is used to write data validators; because it has been designed to accumulate errors with e.g. an input form with multiple input validations that could be in error at the same time.
- etc.
This is by no means a comprehensive list of monadic data types… both for functional programming and on the large, but its also not comprehensive in terms of the C# types that have some level of implementation of functional programming algebras.
What's so useful about deferred evaluation ?
Deferred evaluation is more commonly referred to as lazy evaluation; why is it useful in Linq is simple. it allows a more expressive use of the api without incurring additional computation cost, for example:
- Multiple Where statements in a single Linq computation without the cost of performing each Where computation separately -- it's combined into a single computation.
Allow you to only incur a computational cost when its needed.
For example; some lazy evaluations may be built up during a computation block; and then never executed because of e.g. a branched operation like a cancellation; where this lazy evaluation becomes unnecessary; hence it would be preferable to not incur any computational cost until its actually needed, and most certainly not at each step (e.g. for each dot chained method call).
Infinite Lists
The other less obvious use of lazy evaluation is infinite lists; lists that are computationally far too expensive and/or impossible to compute on the whole… that is where method calls like Take, Skip come into play, for example:
- I can choose to Skip the 1st 3 entries in an infinite list of primes, and Take the next 4; without incurring the computation cost of trying to 1st populate an infinite list of primes.
Isn't deferred evaluation dangerous because you have no idea of what might have changed in the time between assembling the IEnumerable and iterating/evaluating it ?
No not at all; because the final computation would still work on essentially a snapshot of the encapsulated value at the time the lazy evaluation was computed.
Plus its considered bad design to build any system that incorporates data races — a data race occurs when two computations access the same value concurrently, and at least one of the accesses mutates the value. The problem is that it makes testing impossible, because you have no way of knowing the state of the encapsulated value; worse the mutation step may only be partially computed; leaving the value in a compromised state. It makes it impossible to test code with objects that are in an indeterminate state.
Why can't I test an IEnumerable to see if it's empty, or null; why do I have to trigger iteration with 'Count() to see how many items it has, and, why can I only use 'Any to see if there are no items in it without triggering iteration..
…because its a lazy evaluation — which is typically impossible (if not difficult) to predetermine in advance of actually computing the lazy evaluation. However Microsoft as of .Net 6 has made available a new Linq method called TryGetNonEnumeratedCount which attempts to determine the number of elements in a sequence without forcing an enumeration; failing which it reverts to forcing the compute.
Personally I would advise against this style of coding completely + in the functional programming context; we specifically avoid these types of method calls, because they are indeterminate; worse this method mutates an input parameter (out keyword) -- which makes testing that much more difficult. In functional programming; there is huge merit in trying to keep a majority of the codebase as pure as possible. In the C# context; it is quite possible to have the core of the codebase pure; with a very small cut out for mutation where its unavoidable, for example: UI. Leaving a codebase that is for greater part very easy to test, and hence less prone to errors.
Anyway that's a window into the rabbit hole that is functional programming and its basis in category theory; hopefully its helpful.
modified 26-Jan-22 12:01pm.
|
|
|
|
|
It's an interface to a forward reading state machine who's final implementation is left up to the author. The whole "internal list" concept is an illusion.
I use IEnumerable to create custom tokenizers for certain text files. It's when you need it, and realize it, that its usefulness becomes clear.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Most certainly Yes... in the context of considering IEnumerable as just an interface for iteration over a collection of sorts.
What however muddles the water is the questioning of its usefulness in relation to the Linq Extension Methods for IEnumerable, as mentioned by OP:
- Select
- Where
- Aggregate
Similarly deferred evaluation aka lazy evaluation and Count()
Whilst most any data type can conform to some degree with IEnumerable, and by virtue its Linq extensions; it's predominant practicality is with in memory collection types like List, where a majority of the Linq algebras would equally be useful, performant, etc.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
