|
No, what I meant was how are you defining the selected items property?
I assume something like:
public partial class Text_List_Dialog: Form
{
...
public List<string> SelectedItems
{
get
{
List<string> items = new List<string>;
for (int i = 0; i < ListBox1.SelectedItems.Count; i++)
{
items.Add(ListBox1.SelectedItems[i].ToString);
}
return items;
}
}
...
}If not, what are you doing?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
You could set make your listbox public, and in your form closing handler, just do something tith form.listBox.SelectedItems.
Of course there are a number of ways to handle this, and this is just one of them.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Visual studio .Net 2008 C#
User toolbar editing example code please....
don't find search in codeproject example code..
|
|
|
|
|
Hi -
I have a piece of C# code that write message log to Database. Now I would like to create unit test scripts using Visual Studio Unit Test framework.
I need to create Unit Test code to verify if the data is written properly to the database or not.
How do I write code or what mechanism I should use to verify this.
Thanks,
Shub
|
|
|
|
|
See here[^].
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
Well in my opinion doing a unit test does not involve actually seeing if the data got written properly to the database. That is an integration test in my opinion. Unit tests should just test that module and nothing else. I would make a mock database adaptor and have the test make sure all the proper commands where made to the adaptor from your code. To me this is a truer unit test.
Leon Lambert
|
|
|
|
|
You have two choices.
First choice is actually write the data to the Database, ideally within a transation so that it can be rolled back. You need to be able to run your Unit Tests repeatedly without leaving a mess behind.
Second Choice is to Mock the Database. If you haven't designed your app from the start with this in mind then it can be tricky to retrofit.
If you need more info on Mocking just ask.
-Rd
Hit any user to continue.
|
|
|
|
|
Ok, I've been working on a user control that basically houses a FlowLayoutPanel control and allows you to add PictureBox Controls through code. The adding part works, however the code that removes the PictureBox's only seems to remove the ones that are visible.
This is the code that removes the controls:
public void RemovePictures()
{
foreach (Control pic in flpPanel.Controls)
{
pic.Click -= PictureClicked;
flpPanel.Controls.Remove(pic);
pic.Dispose();
}
}
flpPanel is a FlowLayoutPanel as I stated above.
Am I doing something wrong, is this a bug? I am using Visual C# Express 2010 and building in .Net Framework 4.0
Update:
A look at the Methods supported by the ControlsCollection class i see a Clear() method. (I should have guessed considering its a collection) Anyway, I'm worried about using this rather than what was above as Clear() does not give me the ability to unhook the event from each picture box...
Anyone have an idea of whether this is a bad thing?
modified on Thursday, October 7, 2010 10:34 PM
|
|
|
|
|
Charles Cox wrote: Am I doing something wrong
Many things in fact.
1.
there is no need to remove the click handler if the control is going to disappear.
2.
within a foreach over some collection, you can't modify the collection. You can modify the content of the collection (say change a property), but you can't add or remove. If that is what you want to do, don't use foreach; use a regular for loop instead.
3.
if a PictureBox is showing an image that you created (say Image.FromFile or new Bitmap), then you should remove the image from the PictureBox, then dispose the image, and then dispose the PB.
Charles Cox wrote: only seems to remove the ones that are visible.
you should state facts, as strict as possible. I suspect your situation is: the code throws an exception at the Remove() line. If so, say so. You'll get more/better/faster help, and you'll learn to help yourself by looking for detailed symptoms.
In all, visibility of PB's doesn't factor in as far as I can see.
|
|
|
|
|
1.
Okay.
2.
I have the same problem with a for loop.
3.
Okay. I will try this.
4.
No Exceptions are raised. To be more clear, when the RemovePictures() method is called, it removes some of the PB's but not all. From what I can see (And count) it only removes the ones that are currently showing in the FlowLayoutPanel (without scrolling down).
I see now that like most other collections there is a Clear() method. Would this be better to use?
|
|
|
|
|
Charles Cox wrote: there is a Clear() method. Would this be better to use?
Probably not.
1. if you don't succeed in enumerating the PictureBoxes, you may not be able to dispose of the images they are showing.
2. Clear() would remove everything, even Controls that you might want to keep, if any.
I suggest you increase the observability: log the number of PictureBoxes you create and add to the FLP; log how many there are in FLP.Controls; log each iteration of your foreach/for loop; and you are likely to see what goes wrong where.
|
|
|
|
|
I rework of the methods for loop seems to make it work. Rather than incrementing through the collection I start at the end and work my way down.
public void RemovePictures()
{
ControlCollection controls = this.flpPanel.Controls;
PictureBox pb;
for (int i = controls.Count -1; i > -1 ; i--)
{
pb = (PictureBox)controls[i];
pb.Image = null;
this.flpPanel.Controls.Remove(pb);
}
}
I am still unsure what you mean by disposing the Image of the PB. Aside from the fact that the variable used to assign it to the PB already being disposed each time its used in the Add method.
Is what I have done above (setting it to null) what you mean?
|
|
|
|
|
if your PB is showing an image and holds the last reference to said image, you need to call Dispose() on that image (see the Image or Bitmap class in MSDN). So the right order is:
- get the image ref
- set PB.Image null
- dispose of Image
Your backward for loop is OK; forward would work also as long as you remove element zero all the time. What you forgot is the Controls collection gets adapted every time you add/remove something (that also was why foreach did not accept the removal). The best way to remove all is:
while (!collectionEmpty) { doWhatItTakesOnElementZero(); removeElementZero(); }
|
|
|
|
|
Thank you very much for the help.
I think I understand the problems I was having now.
Cheers
|
|
|
|
|
You're welcome.
PS: it is custom here to up-vote useful messages, that is how reputation gets built.
|
|
|
|
|
Sorry, was not aware.
But otherwise thank you.
|
|
|
|
|
No worries.
|
|
|
|
|
Hi all
I have a rather big GUI application in C# (.NET 2.0, VS2005), which takes some time when first started (its IinitializeComponent method, along with some other setup actions I am doing takes about 4-7 seconds).
I want to present the user an 'Opening screen' that will be presented while the application gets loaded, and once it finishes, this 'Openning screen' will be vanished.
I have tried to 'show' the 'Openning screen' form before starting my applic, but it fails to be drawn completely and fails to shut off when my app finished its setup (since the main thread can't reach its close statement as it stays on the message loop of my main app).
Here is some pseudo code:
[STAThread]
static void Main(
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
OpenScreenForm op = new OpenScreenForm();
op.show();
MainApp m = new mainaApp());
Application.Run(m);
op.Close();
}
I have tried using other thread to show the openning screen, and joins him (by the main thread), so that I could make sure that the form finished its showing stuff, but this also failed (openning screen gets shown for a glimpse and hides back..)
Here is some pseudo code:
[STAThread]
static void Main(
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Thread openThread = new Thread(new ThreadStart(CreateOpenningForm));
openThread.Start();
openThread.Join();
MainApp m = new mainaApp());
op.Close();
Application.Run(m);
}
...
static void CreateOpenningForm()
{
op = new OpenScreenForm();
op.Show();
}
Does any one has any idea how to accomplish that ?
Thanks in advance
|
|
|
|
|
What you want is known as a "splash screen"... Google that, and you'll be overwhelmed with the amount of material out there 
|
|
|
|
|
most of which unfortunately isn't any good, either the splash lacking functionality, or being shown for a fixed amount of time, or it all being threaded the wrong way. There are dozens of CP articles on the subject, and I still feel an urge to add one.
|
|
|
|
|
|
The functionality seems fine, the threading seems all wrong though. Forms must be created and shown on the main thread, otherwise you'll get all kinds of trouble. See the most recent thread in that article's forum.
|
|
|
|
|
This splash screen functionality is even a killer for my current needs.
By saying that the threading seems wrong, you must be refering to the cross-thread oporation that this program will face, since creating the splashing form not in the main thread, but accessing to it with it any way...
Well that is well known problem (that can be bypassed, if you know what are you doing) but it cerenally lies in the killer aspects of this splash screen from my point of view so it won't bather me (as I am planning to eliminate it to begin with..)
Thanks all for your help and remarks
Shultz
|
|
|
|
|
|
You might want to investigate this tip/trick:
Multiple Subsequent Main Forms in C# Apps[^]
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
