|
What Pete is suggesting is a dummy project to prove where the fault lies: create a minimal sample that doesn't have the problem, add the Add method and see if it fails. If it does, put it up on Github for examination.
If it doesn't ... then the Add addition is probably coincidental, and you broke something else at the same time!
"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!
|
|
|
|
|
OriginalGriff wrote: the Add addition is probably coincidental, and you broke something else at the same time
Absolutely sure: by renaming "Add" to "AddHazardLocation" the problem was solved.
I did the analysis step by step - tedious minimal steps. Nothing else was changed at that moment.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
Creating "empty" interfaces seem questionable to start with.
public interface IHazardLocation {}
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I wrote some codes in DevExpress spreadsheet which gets information from a sheet and then put them into a dictionary and after that do some calculations and at the end creates a new sheet and fill the cells with calculated data.
I want to use a progress bar for the whole process. I created a progress bar and tested it with a sample value of 50. When the calculations start, progress bar is in freezed status and shows nothing. When the background calculations end, the progress bar unfreezed and show 50%.
How can I solve this problem?
modified 7-Feb-21 22:28pm.
|
|
|
|
|
Please explain how you're running the background task, and how you let it report progress updates to the progress bar.
|
|
|
|
|
I'm going to update the progress bar based on each row is filled at the new sheet. I tried to test it with a constant value of 50 and noticed that it freezes until the end of the calculations. The calculations consist of the following steps: 1. Data is read from a sheet into two Lists. One list is string type and another is integer type. String type list consists of values of 4 cells in each row.
2. Lists are put into a dictionary. Strings are keys and integers are values.
3. Values of the same keys are summed.
4. The mentioned two lists are cleared and fill by dictionary keys and values.
5. Dictionary keys and values are split into cells in a new sheet.
modified 7-Feb-21 22:38pm.
|
|
|
|
|
_ = Window.Current.Dispatcher.RunAsync( CoreDispatcherPriority.Normal, () => {
} );
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
When you execute a lengthy operation (any computation exceeding say 50 msec, but also anything that might occasionally be slow, e.g. an internet access) in one of the GUI event handlers (e.g. a button's Click), it will block the main=GUI thread, as a result your GUI freezes.
There are a number of bad attempts to fix this. The good ones all involve another thread, but then, beware, other threads are not allowed to touch your GUI Controls. The recommended approach is by using one BackGroundWorker; it will perform the bulk of the job on a separate thread, yet it provides a progress reporting event which automatically does run on the main=GUI thread, so that is by far the number one way to keep your GUI alive and responsive.
When the BGW finishes up, it fires a Completion event which typically is used to report all mishaps that may have occurred (make sure to handle its Exception which unfortunately there is called Error), it could also be used to e.g. re-enable a Button; that event handler also runs on the main=GUI thread, again no worries.
If unfamiliar with BGW, look for (a) the documentation and (b) a good example, and study these first. It may seem complex, but it isn't; it is the easiest way into multi-threading, something most applications are bound to take advantage of.
Luc Pattyn [My Articles]
If you can't find it on YouTube try TikTok...
|
|
|
|
|
I have a C# console application that is launched from a WinForm application.
The output of the console application is well-formatted; however, user can run the console application directly. Is there a way to restrict/force the console application to be only run from the main application (WinForm)?
|
|
|
|
|
Pass a mystery parm to the console app that only the Windows Form knows about. No parm, no run.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
You can easily get the command line parameter from Task Manager, so the passed value should be changed every time it needs to be launched. I was thinking the parameter could be randomized or something else, then verified over a named pipe, or other IPC, with the WinForms app.
|
|
|
|
|
I was counting on the "user" being "typical" ... Task Manager? Wazzat?
This looked like an "inhouse" solution ... Anybody trying to bypass this simple solution is obviously asking for trouble.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
The thing about your "typcial" user is that some of them stumble across how to do things they shouldn't normally know how to do.
NEVER assume users stay uninformed. Security is only secure in an environment that never changes or is touched from the outside, and that's never the case.
|
|
|
|
|
There's a difference between "accidently" running a console app versus defeating a method intended to prevent "accidents".
Yes, there is a chance someone will type: ConsoleApp.exe supercalifragilisticexpialidocious.
There is also such a thing as overkill based on what the console app actually does.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Oh I get it, I've been here before. I speak from experience I cannot talk about.
|
|
|
|
|
One size does not fit all.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
There's no direct way to stop the console app from being launched, no.
Applications always run as the user account that launches them. So if the user launches your WinForms app, it's running as the user, or it inherits the users security token. Any other processes your WinForms app launches inherits the environment and security token of the app that launched it.
You cannot prevent the user from running the console app. This would prevent the WinForms app from also launching it.
So, you have to get creative. You could have the console app look for a mutex the WinForms app creates, or use some interprocess communication channel between the WinForms app and the Console app, so that there is at least a mechanism for the WinForms app to say something like "yes, it's OK for you to run".
|
|
|
|
|
Just to add to what the others have said, If it's never to be run by the user, why create a console app at all?
Why not just run it as a separate thread within the existing WinForms process?
"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!
|
|
|
|
|
May I suggest a possible answer?
The shell actually performs some quite useful tasks. If you make extensive use of shell facilities, it may take quite a few code lines to duplicate the functionality in your WinForms code.
|
|
|
|
|
|
As OriginalGriff suggested, you should probably just run it as a thread in the process. But if you insist launching a console app, have your WinForms app create shared memory that your console app will look for when launched. If not found, terminate the console app.
|
|
|
|
|
I have 5 column in a spreadsheet (DevExpress spreadsheet). The first four columns are string values. The fifth column is integer (numeric). I joined those first four columns and put it as KEYs in a list, then collected the fifth column entries as VALUEs in an another list. I used these two lists to create a dictionary.
Now, I want to sum values related to each duplicate keys. As you now, dictionary object throw an exception for duplicate keys. How can I sum those values related to each duplicate keys?
I tried this:
IWorkbook workbook = spreadsheetControl.Document;
Worksheet worksheet = workbook.Worksheets.ActiveWorksheet;
CellRange range = worksheet.GetDataRange();
int LastRow = range.BottomRowIndex;
var keys = new List<string>();
var values = new List<int>();
for (int i = 0; i < LastRow + 1; i++)
{
keys.Add(string.Join(",", worksheet.Cells[i, 0].DisplayText, worksheet.Cells[i, 1].DisplayText,
worksheet.Cells[i, 2].DisplayText, worksheet.Cells[i, 3].DisplayText));
values.Add((int)worksheet.Cells[i, 4].Value.NumericValue);
}
var mydic = new Dictionary<string, int>();
for (int i = 0; i < keys.Count; i++)
{
try
{
mydic.Add(keys[i], values[i]);
}
catch (Exception)
{
if (mydic.ContainsKey("f,a,r,d") == true)
{
MessageBox.Show("Duplicate");
}
}
}
I need to replace
if (mydic.ContainsKey("f,a,r,d") == true)
{
MessageBox.Show("Duplicate");
} with another code.
modified 2-Feb-21 12:48pm.
|
|
|
|
|
Ummm...why don't you check to see if the key already exists and if it does, just add the value you have to the value that's already in the dictionary?
if (keys.ContainsKey(key))
{
keys[key] += value;
}
else
{
keys.Add(key, value);
}
Easy. No exception handlers needed, nor goofy ass other code to handle a duplicate key.
|
|
|
|
|
"keys" object is an instance of list class. It doesn't support "ContainsKey" method.
|
|
|
|
|
OK, why are you making a list of keys?
Why are you making a list of values?
You mention you're using a Dictionary, so why the lists when the dictionary can do everything you're taking about so far.
|
|
|
|