|
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.”
|
|
|
|
|
Not sure what problem are you facing. Nested properties (not sure this wording also correct) are trivial to implement. Here is a C# implementation as my VB is poor.
class Employee
{
Address homeAddress =
public Address HomeAddress
{
get
{
return homeAddress;
}
}
}
class Address
{
string street;
public string Street
{
get
{
return street;
}
}
string city;
public string City
{
get
{
return city;
}
}
} Now you can write,
Employee chuckNorris = new Employee();
chuckNorris.HomeAddress.Street = "Set the street here";
chuckNorris.HomeAddress.City = "set the city here";
|
|
|
|
|
This, I all understand.
My problem lies specifically within the Size property, as I'm trying to overload it, along with the properties that the Size property has (specifically height and width).
|
|
|
|
|
So you need to expose a property that has all the properties of Size available and your own custom properties. Is that right? If yes, you need to create a completely new type. Also I just noticed that Size is a structure and you will get a compiler error if you write
control.Size.Width = some value
If you are creating new type, I would consider a class over a struct.
|
|
|
|
|
Thanks I'll look into that, but out of curiousity are you saying that if I have a button, I cannot do..
button1.Size.Width = 60
I must have misunderstood your post, I think I'm going to tackle this another way..
|
|
|
|
|
Since struct is a value type, button1.Size returns a copy of original size. Changing a property value on it won't affect the original size instance which is in the control. So you need to do
button1.Size = new Size(width, height)
Hope that is clear
|
|
|
|
|
... or button1.Width=width;
|
|
|
|
|
My memory seems to be fading away from me here, you are both correct. My mistake.
|
|
|
|
|
How to . Which data provider can use to implement that.
|
|
|
|
|