|
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
|
|
|
|
|
Hi. I want to develop an application where initially i have just an empty form with no functionality. Then, later, i can develop separate modules and when i install them, they plug themselves into the form with their functionality. Something like add ins. How can i do that?
Wamuti: Any man can be an island, but islands to need water around them!
Edmund Burke: No one could make a greater mistake than he who did nothing because he could do only a little.
|
|
|
|
|
One very common approach in .NET is via reflection/functional interfaces that add-ins should implement. Here's an 8 year old article on the topic:
Using reflection to extend .NET programs[^]
The concepts remain similar even today.
|
|
|
|
|
|
Microsoft has produced the Managed Extensibility Framework[^] that might be appropriate. It doesn't do anything specific to making pluggable parts of forms, but it does the work of dealing with dependencies on plugins that may or may not be there, etc.
|
|
|
|
|
Ummm... with plugins?
and XML. 
Wamuti wrote: they plug themselves into the form with their functionality
I hope they don't try to position themselves on the form.
I've used plugins for background (non-UI) stuff, to populate a TabControl, and to populate a menu, but not for actual controls on a form.
|
|
|
|
|
I would like to build a basic ping application. I've seen a few ping applications here that are well developed and a little complicated for me to dissect and figure out how they work at this point in my learning.
Does anyone have a console ping application that is bare bones, that I can build off of while I learn? Something that I can launch and hard code variables into, and break and the put back and see how it functions?
Thank you!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
