|
I just got done telling someone else this same thing. You cannot have the same instance of a control in two different containers (forms) at the same time. You can add the combo to the controls collection of the second form by first removing it from the controls collection of the first form. You'll have to move it back before your second form is destroyed or dismissed.
20,000 items in a combo?? I'd seriously rethink the design...
|
|
|
|
|
Thanks Dave,
20,000 items is the maximum, but normally I need to fill the Combo with less than 10,000 items getting data from a text-file.
Applying your suggestion, items are preserved , or will be necessary to re-populate the Combo?
Ignazio
|
|
|
|
|
Hi,
1.
As Dave said, a Control has a single Parent, i.e. one Form holding it. You can't make it work reliably on two forms at the same time.
2.
You might consider replacing your two forms by a single form holding:
1. the common controls (including your ComboBox) once;
2. a TabControl so you can choose which TabPage you want to see (so these pages would contain what was not common on your forms).
3.
anything above 100 items in a list for a user to choose from is a GUI horror. You should avoid this both for the user comfort and for performance; there are many ways to avoid it, most of them have a two-level approach: select something (maybe the first letter of a name, a range of values, a page number, whatever), then in a second control show what satisfies the first selection.
One elegant example is a collapsed TreeView: show all the top-level nodes, but only load the details when one of the nodes gets expanded.
|
|
|
|
|
Hi,
Your suggestion to implement a Tab Control is to consider if in this way there is not the need to re-populate the combo 2 times.
I choosen a Combo to contain 10,000 items as compromise between several exigences including the limitaded space available in a mobile device.
I tryed to use a DataGrid, but I confess I encoutered some difficulties.
Thanks
Ignazio
|
|
|
|
|
with the ComboBox outside the TabControl it would always be visible and have no need to repopulate, unless you want to.
|
|
|
|
|
I have a Class DLL that contains a series of functions to perform calculations, i then have a test console application that calls the class, in this instance the class completes its task within about 10 seconds. I then implemented the same class file, as they are all inside the same solution into my windows form application, set it up to be passed exactally the same data and then ran it, it seems to be running about 100x slower in the windows form application as it was still running on the same data after 5 minutes...any ideas why this would be occuring?
|
|
|
|
|
The difference seems a bit large, but then a lot depends on the size of your windows application, and on whether it needs to do a lot of other things besides running the calculations.
The principle behind the difference is simple. Your console application does not do anything else but perform the calculations, whereas the windows application also runs all the graphical stuff, at the same time when it is trying to do the calculations.
Kind of the same thing as when you copy files with Windows Explorer, or with a console app. The console app will do it much faster, because it doesn't have to bother with showing you graphically what is happening.
My advice is free, and you may get what you paid for.
|
|
|
|
|
That is a huge difference and I am sure that there will be something else that is causing this problem. Hard to tell more as you haven't provided any relevant code snippets. Few questions,
1 - Which build are you running? Release or Debug?
2 - How are you calculating the time?
3 - What your windows application is doing other than calling your class? Time may be spending there.
|
|
|
|
|
Tried both build modes, no difference, time is calculated by how long the program takes to run, the class itself has a form with a progress bar, in console mode the progress completes quickly, in windows form, the progress bar moves extremely slowly.
windows application calls the class, then waits for it to finish. I have tried spawning it into a new thread then having the main application wait for the thread to finish, i have also tried calling it inline, rendered no difference in speed, or lack thereof.
Code snippets are hard as there would be pages of code to even make it all understandable if i did, but it is basically running an recursive sub, up to about 6 levels deep on approx 140 different values, sorting and allocating them around as necessary... then returning a collection of results.
|
|
|
|
|
oRiCLe wrote: time is calculated by how long the program takes to run,
No, no, no. What methods are you USING to calculate the time? Not WHAT are you timing.
oRiCLe wrote: in console mode the progress completes quickly, in windows form, the progress bar moves extremely slowly.
In the console app, there is no progress bar, so the thread isn't doing anything else. In your Windows app, the ProgressBar needs to be redrawn every time you update its value. So, if you're changing the value of the ProgressBar on every iteration of your calcuation, your slowing down your calculation speed dramatically since you're making a change to a property value and you're redrawing a control. Like Luc said, without seeing how you're doing this, we really can't tell you what you did wrong.
oRiCLe wrote: Code snippets are hard as there would be pages of code to even make it all understandable if i did, but it is basically running an recursive sub, up to about 6 levels deep on approx 140 different values, sorting and allocating them around as necessary... then returning a collection of results
If the windows app is written properly, and you don't move the mouse while the app is running, there will be very little to no difference in speed between the two apps.
|
|
|
|
|
There is no valid reason whatsoever why a windows app would be any slower than a console app, provided the coding is correct.
without any code nor any detail all we can do is guess.
my best guess is your calculation takes a huge number of very fast steps and tries to show progress after each little step; repainting a progress bar takes some time, if this costs 100 times more than the calculation itself, it would slow down your app by a factor of 101.
Hence, as a test remove the one statement that updates the progress bar.
As a solution, don't update the progress bar that often.
Anyway, if your screen is 1000 pixels wide, a typical progress bar can only show 1000 different states.
|
|
|
|
|
hi mates,
i don't know where to put this question in message board. anyway, i code in visual basic so i think im in the right board.
here's my problem.
how can i correct this query..
SELECT TOP 10 Avg(CONVERT(real,LTRIM(M_Table.Unit))) AS rValue
,Max(CONVERT(real, LTRIM(M_Table.Unit))) As UnitMAX
,Min(CONVERT(real, LTRIM(M_Table.Unit))) As UnitMIN
FROM M_Table
Is it possible to have a Trim inside the convertion?
If not, does anybody know how can i do it.
I want to convert the M_Table.Unit from nvarchar to real. Where M_Table.Unit is nvarchar
but some of M_Table.Unit has space from the beginning which is got an error "cannot convert real to nvarchar" due to that space that's why i want to remove all whites spaces from the beginning of M_Table.Unit.
C# コードMicrosoft End User
2000-2008
「「「「「「「「「「「「「「「「「「「「「「「「「「「「
The best things in life are free
」」」」」」」」」」」」」」」」」」」」」」」」」」」」
|
|
|
|
|
I almost solve my own problem
i just change this line from
Max(CONVERT(real, LTRIM(M_Table.Unit))) As UnitMAX <br />
to CONVERT(real, LTRIM(Max(M_Table.Unit))) as UnitMAX
but only 1 remaining problem is this line
SELECT TOP 10 Avg(CONVERT(real,LTRIM(M_Table.Unit))) AS rValue
help me.
thanks.
C# コードMicrosoft End User
2000-2008
「「「「「「「「「「「「「「「「「「「「「「「「「「「「
The best things in life are free
」」」」」」」」」」」」」」」」」」」」」」」」」」」」
|
|
|
|
|
There is a separate forum for specific sql questions like this.
However, what does the query analyzer say, is wrong with that line? Or is the problem, that the query is not returning the expected result?
My advice is free, and you may get what you paid for.
|
|
|
|
|
First, this is entirely a database question, not VB.NET. You're looking for this[^] forum.
Next, if your data in the table was normalized when it was inserted into the table, this little problem would never have come up. Now, on retrieval, your making the database engine do a lot more work and slowing down the process of retrieving your data.
|
|
|
|
|
Hi
Is there a way to duplicate a toolstrip from a form to another?
I tried New_Contextmenu.Items.AddRange with the items i want to duplicate and it removed those items from the original strip, then tried to make a new ToolStripMenuItem for each item, and expecting to create a completely new instance of the items by using the "NEW" keyword, But seems I can't get it right and j's are still referencing the original i items and generates error by removing items from the original toolstrip.
Public Sub MakeNewStrip(ByVal DropDown As System.Windows.Forms.ToolStripDropDown)
For Each i As System.Windows.Forms.ToolStripItem In DropDown.Items
Dim j As New System.Windows.Forms.ToolStripMenuItem
j = i
Me.Clock_Contextmenu.Items.Add(j)
Next
End Sub
|
|
|
|
|
I can't say that I've ever had to do that. But, I would probably create a method that returns a built default toolstrip instead of trying to copy an exiting one. But, have you tried myMenuItem.MemberwiseClone()?
|
|
|
|
|
I solved the problem by using
Me.ToolStripMenuItem1.Items.AddRange(New System.Windows.Forms.ToolStripItem() {....})
in the Opening event of each menu strip.
That way I don't have to handle the events of the items separately and a single code works for both.
But I still don't understand why the first code didn't work, I even created a new list of the items and populated the list with "New" instance of the items but adding the list to the new menu would remove them from the original one  .
Thanks anyway
|
|
|
|
|
All UI controls can only haev one parent container. You tried to have the same control have two parent containers. Doesn't work that way.
|
|
|
|
|
This code, to open and read a local access 2007 database, works perfectly fine on my (Vista) development station:
<br />
'open the Access 2007 database without a password<br />
Dim DBconnection As OleDbConnection<br />
Dim DBcommand As OleDbCommand<br />
Dim DBdataReader As OleDbDataReader = Nothing<br />
Dim strProgramPath As String = System.AppDomain.CurrentDomain.BaseDirectory()<br />
Dim strDBfullPath As String = strProgramPath + "labs.accdb"<br />
DBconnection = New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0; Data Source=" + strDBfullPath + ";Persist Security Info=False;")<br />
DBconnection.Open()
However, once I copy my program to the Windows Server 2008 machine as well as the same database I used for development: 1) the code above takes a long time to execute 2) .Open fails
Why does it work fine on Vista, but fails on Server 2008 eventough the database on both machines are the same ?
|
|
|
|
|
so the problem here seemed to exist because the compilation was set to "any CPU".
Once I set the compilation option to x86, the application was able to open the database on the Server 2008 machine too (64bit machine).
So it seems there's no 64bit driver to access an Access 2007 DB ?
I'm glad it's at least working now, however, on my (32bit) Vista development station the data access is very fast and on the (64bit) Server 2008 station data access is very slow; instant vs. 30 secs
|
|
|
|
|
Best Of Regards,
SOFTDEV
Sad like books with torn pages, sad like unfinished stories ...
|
|
|
|
|
abiemann wrote: So it seems there's no 64bit driver to access an Access 2007 DB ?
True, at this time there is no 64-bit drivers for a Jet database (Access). Since you cannot mix 64 and 32 bit code in the same process, you have no choice but to compile your app forced down to 32-bit only. If you used any of the SQL Servers, including SQL Server Express Edition, you wouldn't have this problem.
|
|
|
|
|
I wish to create a property which has sub properties (sorry if this is the wrong wording) similar to the Size property each control already implements..
Control.Size returns System.Drawing.Size
whereas you can still access
Control.Size.Width returns an Integer
I suppose sub property would be the best word to describe the 'Width' property
Any ideas how to implement this hierarchy of properties on your own custom properties?
|
|
|
|
|
You need to apply a TypeConverter attribute, specifying either an ExpandableObjectConverter, or one derived from it.
Using PropertyGrid Part-I[^] has an example (and googling might find others that more directly address this), search for ExpandableObjectConverter for the relevant bit.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
