|
I was trying to be cheeky, of course the static set of buttons is a lousy design, I generally use a combobox if the user has multiple roles.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
You need to completely isolate the log-in process from the display of any UI, using the guidelines for DB access, and password encryption, you've received on this thread.
Once you have a valid log-in, then run the app that shows the UI (using Process.Start, or some other technique).
You can create a Form as a template that will contain all the Controls shared by every role, and, then, create other, role-specific, Forms that inherit from the template.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
We're drowning a beginner here Still, you are right; you explained the what, I'll add the why.
When you have a button on a WinForm, you can inspect its properties. So, if I see a disabled button, I'll simply toggle the "enabled" property to gain access. If there's no button visible, I'll look at the form and check if there's an invisible button as a child. That means hiding/disabling buttons is not secure.
Use the .NET Windows Forms Spy[^]
I dislike the idea of asking the user for a password in WinForms; if need be, all assemblies can be decompiled, adapted, and recompiled. For ASP that's less of an issue - but then I'd assume an AD that does the authentication, which means you don't need to provide yet another login.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: When you have a button on a WinForm, you can inspect its properties. So, if I see a disabled button, I'll simply toggle the "enabled" property to gain access. If there's no button visible, I'll look at the form and check if there's an invisible button as a child. That means hiding/disabling buttons is not secure. If you believe the OP is a "beginner," do you think they will understand this ?
Eddy Vluggen wrote: I dislike the idea of asking the user for a password in WinForms; if need be, all assemblies can be decompiled, adapted, and recompiled. For ASP that's less of an issue - but then I'd assume an AD that does the authentication, which means you don't need to provide yet another login. If the app stores no passwords, how can any form of hacking the app discover them ... for that matter, lots of Winform apps consume the plain-text user-entered password, hash it, salt it, and use that to query the DB for a check.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
BillWoodruff wrote: If you believe the OP is a "beginner," do you think they will understand this ? No, but more people reading this thread then OP, no?
BillWoodruff wrote: If the app stores no passwords, how can any form of hacking the app discover them ... That's the point; if you leave the authentication to the AD, there's little risk.
BillWoodruff wrote: for that matter, lots of Winform apps consume the plain-text user-entered password, hash it, salt it, and use that to query the DB for a check. In which case you can decompile, and add a logging-statement for the unsalted variables, recompile.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: When you have a button on a WinForm, you can inspect its properties. I just tried that but could not find how to view or change the properties.
|
|
|
|
|
Can't find the app right now, but there's an application that lets you change values of properties of a running .NET application. It is similar to the WinSpy-app.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Not quite the same as "inspect the properties, and change them".
|
|
|
|
|
It was possible with that application, with the exception of readonly properties.
--edit
Similar to Accessibility tools - Inspect - Win32 apps | Microsoft Docs[^], which is already obsoleted. Buggy internet today, so Googling may take a bit
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
modified 10-Nov-19 13:41pm.
|
|
|
|
|
Eddy appears to be using a very expensive (UFT from MicroFocus, US $ 2~3k per seat) testing engine with some .NET add-in.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Nah, it was something free; but there's a boatload of links for the searchterms. I'll post a link in the lounge if I stumble on it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Using .NET: Deliver The Power Of Spy++ To Windows Forms | Microsoft Docs[^]
MS wrote: When you select a control, the PropertyGrid shows properties on that control. You can examine or change property values here. You should note that custom types are supported as long as they are binary serializable (see Basic Serialization). It will fail with an exception when you run it. There's similar code on Github, which I haven't tried yet. If you want the link, drop me a message.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I don't see how all this relates to this thread. The issue here is not what you can do by hacking, but how to securely isolate password login from the app that runs after successful login.
The link you posted was to the expensive MicroFocus tool
cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
BillWoodruff wrote: he issue here is not what you can do by hacking, but how to securely Our ideas on security may vary; I do not see any login in .NET WinForms as being "secure".
BillWoodruff wrote: The link you posted was to the expensive MicroFocus tool The first, yes, because I could not find the tool imediatly. The second link points to MSDN which will fail on W10.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I have the following C # statement:
...
using (SoundPlayer player = new SoundPlayer(Properties.Resources.ring))
{
player.Play();
while (If the bell is running, wait here)
{
if (player.Stop()==true)
{
this.progressBarControl1.Visible = false;
}
}
}
...
I want to check if the ringer is running or stopping, if it is running then wait until it stops before running this.progressBarControl1.Visible = false.
|
|
|
|
|
If you need to know when the sound has finished playing, you'll have to use the PlaySync method[^].
However, if you do that from the UI thread, your application will stop responding until the sound finishes. You'll probably want to play the sound on a background thread to avoid this problem. The simplest option would probably be to use a BackgroundWorker instance[^] - put the SoundPlayer code in the DoWork event handler, and the code to hide the progress bar in the RunWorkerCompleted event handler.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
use PlaySync() runs fine, but using backgroundWorker1 is difficult to use and the computer freezes
|
|
|
|
|
Member 2458467 wrote: backgroundWorker1 is difficult to use and the computer freezes
Then you're using it wrong.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I do not know how to use backgroundWorker in my code so the device crashes, I troubleshoot I see Debug.Print("Status: PLAY") and Debug.Print("Status: STOP") appear only once, You see my code, did I write anything wrong ?
bool _isStopped = true;
public Form1()
{
InitializeComponent();
backgroundWorker1.WorkerReportsProgress = true;
backgroundWorker1.WorkerSupportsCancellation = true;
lblStatusPlaySound.ForeColor = Color.Violet;
lblStatusPlaySound.Text = "Status: PLAY/STOP";
}
private void btnPlaySound_Click(object sender, EventArgs e)
{
backgroundWorker1.RunWorkerAsync();
using (SoundPlayer player = new SoundPlayer(Properties.Resources.ring))
{
player.Play();
}
while (_isStopped == true)
{
if (backgroundWorker1.IsBusy != true)
{ _isStopped = true; }
else
{ _isStopped = false; }
lblStatusPlaySound.ForeColor = Color.Green;
lblStatusPlaySound.Text = "Status: PLAY";
lblStatusPlaySound.Refresh();
Debug.Print("Status: PLAY");
}
lblStatusPlaySound.ForeColor = Color.Red;
lblStatusPlaySound.Text = "Status: STOP";
lblStatusPlaySound.Refresh();
Debug.Print("Status: STOP");
}
|
|
|
|
|
Read my previous message again: put the SoundPlayer code in the DoWork event handler, and the code to hide the progress bar in the RunWorkerCompleted event handler.
You've put all of the code in the button's Click event handler instead.
And as I said, you'll need to use the PlaySync method if you want to wait for the sound to finish playing.
It should look something like:
public Form1()
{
InitializeComponent();
backgroundWorker1.DoWork += backgroundWorker1_DoWork;
backgroundWorker1.RunWorkerCompleted += backgroundWorker1_RunWorkerCompleted;
lblStatusPlaySound.ForeColor = Color.Violet;
lblStatusPlaySound.Text = "Status: PLAY/STOP";
}
private void btnPlaySound_Click(object sender, EventArgs e)
{
btnPlaySound.Enabled = false;
lblStatusPlaySound.ForeColor = Color.Green;
lblStatusPlaySound.Text = "Status: PLAY";
backgroundWorker1.RunWorkerAsync();
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
Debug.Print("Status: PLAY");
using (SoundPlayer player = new SoundPlayer(Properties.Resources.ring))
{
player.PlaySync();
}
}
private void backgroundWorker1_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
lblStatusPlaySound.ForeColor = Color.Red;
lblStatusPlaySound.Text = "Status: STOP";
lblStatusPlaySound.Refresh();
btnPlaySound.Enabled = true;
Debug.Print("Status: STOP");
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hi Richard MacCutchan!
Follow me, the above code can be edited without using RunWorkerCompleted, the program still returns the same result because the PlaySync() method is a sequential command, simple the code will be easier to understand, you see the code below. RunWorkerCompleted event in other cases eg Play() instead PlaySync() method to catch "PLAY/STOP" status for example, do you think ? that is my opinion.
private void btnPlaySound_Click(object sender, EventArgs e)
{
lblStatusPlaySound.ForeColor = Color.Green;
lblStatusPlaySound.Text = "Status: PLAY";
Application.DoEvents();
Debug.Print("Status: PLAY");
using (SoundPlayer player = new SoundPlayer(Properties.Resources.ring))
{
player.PlaySync();
}
lblStatusPlaySound.ForeColor = Color.Red;
lblStatusPlaySound.Text = "Status: STOP";
Application.DoEvents();
Debug.Print("Status: STOP");
}
|
|
|
|
|
Member 2458467 wrote: Hi Richard MacCutchan!
Wrong Richard.
Member 2458467 wrote: because the PlaySync() method is a sequential command
And that's the problem. The thread that calls PlaySync is blocked until the sound finishes playing. If you call it from the UI thread, your entire application will freeze, and you'll get the "Application is not responding" message if you try to interact with it.
It might be OK for a very short sound, so long as you don't expect the UI to update whilst it's playing. But for anything longer than half a second, you need to play the sound from a background thread. Which is where the BackgroundWorker comes in.
Sprinkling Application.DoEvents() calls throughout your code is a hack, and a sign of code which needs to be changed.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ok, if not using PlaySync instead use mciSendString with status command, will this command play sequentially ?
|
|
|
|
|
As far as I can see, mciSendString doesn't wait for the sound to finish playing, so you'd be back to square one.
And if it did wait, you'd still have to call it on a background thread to avoid freezing your UI.
Just use a BackgroundWorker and the SoundPlayer class.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you for answering my questions.
|
|
|
|
|