|
Just worked it out, I can do
var cfg = scope.ServiceProvider.GetService<IConfiguration>();
to get the configuration service, and from there I can get my connection strings 
|
|
|
|
|
Good morning,
As part of my conduit fill program, I have 8 comboboxes that require the same data filled into each one. They all have the same naming convention, but numerically different.
cbo120VACType_1
cbo120VACType_2
cbo120VACType_3
cbo120VACType_4
cbo120VACType_5
cbo120VACType_6
cbo120VACType_7
cbo120VACType_8
How can I setup the naming to be dynamic in my program, so that it will fill each one, one at a time.
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
The simplest way is to use an array / List of ComboBox items and preload it with the boxes to be filled.
Then a simple foreach will do what you want.
"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!
|
|
|
|
|
Is this the same data you were previously considering how to store? A lot depends on how much data, how much the data changes, and in how many places you need the data.
Suppose this one form with the eight combo boxes is the only place where you will need this data. You had mentioned building some kind of calculator or estimator, so it could conceivably consist of just one form. If that's the case, you might consider just manually entering the data in the form designer. Each combo box lets you type in the choices in the list.
A step up from that would be to put the values in an array. Then use that array as the data source to a BindingSource. Then use that binding source as the data source to the first combo box. Repeat the process for the other seven combo boxes. You need one array, but you need a binding source for each combo box. This is because a binding source has only one current position, so if you use the same binding source for more than one combo box, setting one combo box will immediately set all the other combo boxes to the same selected item.
Here's a similar question with code.
c# - Populate a combobox with array information - Stack Overflow[^]
|
|
|
|
|
You should say if you're using Windows Forms or WPF or UWP, etc.
"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
|
|
|
|
|
Oops, thanks. I didn't pick up on that.
|
|
|
|
|
You may be right. I thought WPF (probably because I looked at another WPF post first. I hate when I do that).
"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
|
|
|
|
|
I was just surprised to hear WPF doesn't use Binding Source. I guess I'll find out what it uses when they pry WinForms out of my cold, dead hands.
|
|
|
|
|
The WPF CB's have an ItemSource property which can share a collection and still maintain their own positioning. So it's easier. 
"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
|
|
|
|
|
Is there a preferred way (or is it even possible) to implement some kind of scheme so that only authorized applications are allowed to connect to my service's named pipe instance?
I understand that I can use the PipeSecurity object to control what users are able to connect, but how do I limit it to only authorized applications?
EDIT: I know it's possible, but what is the preferred way of doing it?
The difficult we do right away...
...the impossible takes slightly longer.
modified 26-Jan-22 14:47pm.
|
|
|
|
|
|
Thanks Luc. I think what I'll do is verify the signature of the file that's connecting, and then only allow executables that are signed with my certificate.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Interesting. If that works, it could be a worthy subject for an article...
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.
|
|
|
|
|
Richard Andrew x64 wrote: verify the signature of the file that's connecting, and then only allow executables that are signed with my certificate
Keep in mind that process hollowing[^] could still be used by malicious code to connect to the named pipe by masquerading as your binary. Verifying the signature doesn't give you very much. You would be back to share permissions and file system ACLs accessible by the caller.
|
|
|
|
|
Randor wrote: Verifying the signature doesn't give you very much.
Thanks for the tip.
Keep in mind I'm not only verifying that the signature is valid, I'm verifying that it was signed with my certificate. Does what you're saying still apply?
EDIT: OK I read the article about process hollowing, and you're right. My technique wouldn't defend against it.
Is there any other method you would recommend to secure the named pipe?
The difficult we do right away...
...the impossible takes slightly longer.
modified 28-Jan-22 14:06pm.
|
|
|
|
|
Richard Andrew x64 wrote: Is there any other method you would recommend to secure the named pipe?
Unfortunately Windows is designed to allow processes to modify the memory of other processes running at the same integrity level. I don't think there is any way to do remote attestation on a named pipe that includes memory integrity.
The only thing I can think of would be running your client under the protection of 'Protected Process Light' (PPL) combined with verification of the code signature. But it's not a good solution, (it's very restricting) and not offered to the general public.
|
|
|
|
|
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.)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
