|
I guess you want to the browse to the some path when LogFiles button is clicked.
You need to set SelectedPath property FolderBrowserDialog in button click event.
Isn't it
|
|
|
|
|
yeah thats what I want but I was hoping it could display in the background. Both the folderbrowse and openfile dialog open as modal, it seems, preventing me from doing anything else on the form. I was hoping maybe the folder could open and just sit in background in case the user needed to open one of the files at a later time. I thought there might be a way to do it that didnt require opening an actual file/folder from within the code. Is that not typical?
|
|
|
|
|
I am cofused with Background. If you dont want to show to dialog box than you need to save your log file path in some variable. Nothing else
|
|
|
|
|
|
Hi,
I see three ways of getting a look at a directory:
1. use an existing folderbrowser dialog; since it is a dialog, it will have modal behavior.
2. open up the folder using Windows Explorer; use Process.Start(fileName) to make it happen. This launches a separate process and will behave completely independently of your app.
3. write your own Form that somehow displays folder contents, and Show() it modelessly.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Thanks Luc,
by background, what I really meant was, independent of my application. I wanted an explorer window to stay open regardless of whether or not a file was chosen. I just couldnt explain myself properly.
Process.Start was just what I was looking for!
|
|
|
|
|
Hi,
I think that you want to open a Windows Explorer window at a particular directory for the convenience of your users, correct?
In which case use
System.Diagnostics.Process.Start(pathname) [EDITED typo]
The Start method has many overloads and this simple one uses the associated application to open pathname.
So as an example, if pathname is d:\logfile.txt then Notepad is used to open the file d:\logfile.txt.
What you might not have realised is that directories are associated with Explorer. As a consequence if pathname is a directory, e.g. d:\logfiles then the Start method will open an Explorer windows at the d:\logfiles directory.
Alan.
[EDIT: Like Luc said a few minutes ago]
modified on Wednesday, March 18, 2009 4:09 PM
|
|
|
|
|
Hi,
I dont think i understand correctly.
1. Yes, I do want to open an explorer window, not a file as your example demonstrates
2. I cannot find System.Diagnostics.Start
|
|
|
|
|
Ah, my mistake. If I had written System.Diagnostics.Process.Start, the original post might have made more sense.
In the System.Diagnostics namespace is the Process class and that has a Start method. If you pass a directory path to the Start method it will open an Explorer window at that path.
Alan.
modified on Wednesday, March 18, 2009 3:59 PM
|
|
|
|
|
ah Got it now...
Thanks again for everyone's help
|
|
|
|
|
How do i call a menu form from another menue i have tried the following and not working.
Private Sub RestoreToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles RestoreToolStripMenuItem.Click
Dim frmSecondMenu As New SecondMainMenu
frmSecondMenu. (this did have showDialog in the list of methods)
End Sub
if i type it as frmSecondMenu.ShowDialog() i have the following error
Error: Error 9 'showDialog' is not a member of 'System.Windows.Forms.SecondMainMenu'.
what will i do
|
|
|
|
|
I think you want to call SecondMainMenu's Click procedure in the RestoreToolStripMenuItem_Click()
If you, then
Private Sub RestoreToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles RestoreToolStripMenuItem.Click<br />
<br />
SecondMainMenu_Click(sender, e)<br />
<br />
End Sub
|
|
|
|
|
Why do that when you can simply call SecondMainMenu.PerformClick? That way, you get your function parameters filled in automatically
|
|
|
|
|
Hi everyone,
I started writing programs on VB .NET in the year of 2006, reading Jim Buyens book "Faster Smarter Beginning Programming" and that's only skill I got in programming, so I could say that I'm new in writing programs. My dream was to make my own game, I searched the net to find a simple collision detect system, but all I found was "detecting collisions between 2 or three, or maximum 10 objects" which is pretty simple because there is very small count of objects and we know exactly how much they are. There was nothing like "collision detect between various number of objects", so I've made myself one using the following logic:
I've created a string array which size is equal to the count of the pixels that the playground is made of - if my playground is 9000 x 9000 then the array is something like this: strWorldArr(81000000) - each element in the array represents a single pixel of the playground and all objects that move on the playground fill their name in the elements of the array using their coordinates to locate the elements of the array which represents the pixels beneath them. Here is the code of the main part of my collision detect system:
<pre>REM: checking the pixels before moving the object if the values of the array elements which they present are clean then its good to go:
Function CleanChecker(ByVal panHero As HeroBody, ByVal szeSize As Size, _
ByVal intStartPos As Integer, ByVal intEndPos As Integer, _
ByVal intCycle As Integer)
Dim intCount As Integer = 0
For i = 0 To intCycle
For e = intStartPos To intEndPos
If strWorldArr(e) <> panHero.Name And strWorldArr(e) <> "†" Then
intCount += 1
End If
Next
intStartPos += szeSize.Width
intEndPos += szeSize.Width
Next
Return intCount
End Function
REM: this subroutine cleans behind the object, or fills it's new positions:
Sub CleanOrFill(ByVal panHero As HeroBody, ByVal strChar As String, _
ByVal szeSize As Size, ByVal intStartPos As Integer, _
ByVal intEndPos As Integer, ByVal intCycle As Integer)
For i = 0 To intCycle
For e = intStartPos To intEndPos
strWorldArr(e) = strChar
Next
intStartPos += szeSize.Width
intEndPos += szeSize.Width
Next
End Sub
REM: this subroutine is one of 4 which call the CleanChecker and CleanOrFill to detect a collision:
Private Sub mUP(ByVal panHero As HeroBody, ByVal szeSize As Size, _
ByVal intObjSpeed As Integer, ByVal intTolerance As Integer)
Dim intChkStart As Integer = panHero.Left + intStartNum(panHero.Top - intObjSpeed)
Dim intChkEnd As Integer = intChkStart + panHero.Width
Dim intCleanStart As Integer = panHero.Left + intStartNum(panHero.Bottom - intObjSpeed)
Dim intCleanEnd As Integer = intCleanStart + panHero.Width
If CleanChecker(panHero, szeSize, intChkStart, intChkEnd, intObjSpeed) >= intTolerance Then
REM: the path is blocked
Else
REM: the path is passable
panHero.Top -= intObjSpeed
CleanOrFill(panHero, panHero.Name, szeSize, intChkStart, intChkEnd, intObjSpeed)
CleanOrFill(panHero, "†", szeSize, intCleanStart, intCleanEnd, intObjSpeed)
End If
End Sub</pre>
To pass this code through all of the objects I use For Each... Next statement.
On core2 duo CPU 2GHz 4mb l2 cache and 2GB RAM this system can support smoothly up to 100
objects, on intel Pentium4 1800 MHz 512 kb l2 cache and 1GB RAM this system works so badly that it
can't move even one object normally.
I think that this code is pretty simple, why it takes so much power to run? Is this slow calculation have
anything to do with the programming language - Visual Basic 2008 - .NET Framework 3.5? Is there anyway to
improve the collision detect performance of this system or this project is doomed?
Sorry for my bad english, and thank you in advance.
<div class="ForumMod">modified on Wednesday, March 18, 2009 10:39 AM</div>
|
|
|
|
|
Member 3734843 wrote: I think that this code is pretty simple, why it takes so much power to run?
Well, since String's under the .NET CLR are immutable (cannot change them), every time you make a change to a string you're creating a new 81 MEGABYTE string! Each old string is dropped, by not before the new one is created. Multiply that by the number of times you're making a change to the string and you've quite possibly created the worst collision detection algorithm ever.
Member 3734843 wrote: Is this slow calculation have
anything to do with the programming language - Visual Basic 2008 - .NET Framework 3.5?
Nope. I can assure you, the performance problem is entirely in the design of your algorithm.
Member 3734843 wrote: Is there anyway to
improve the collision detect performance of this system or this project is doomed?
Until you completely rewrite the detection algo to use the processor more efficiently, you're project is doomed.
Using an array of integers should improve performance dramatically. Completely scraping the array and comparing the bounds of object to object would be far better since you don't have to compare against 81000000 pixels every time you more something by 1 pixel.
It comes down to representing your objects more effificently and in a manner that lends itself to better collision detection. Really, pickup a book or two on game programming. I really can't explain how to do something better in a forum post.
|
|
|
|
|
Thank you for the advices, the moving objects I use are actually windows forms, and I'm not comparing all those 81000000 elements with each other - the logic is different but very long to explain in the forum. Now I've just turned off the collision detect system and for my big surprisse I've noticed that nothing is changed - again If I put more than 100 objects(windows forms) to move arund my desktop - the performance is the same as if the collision detect statements are turned on. I suspect that using windows forms as units in the playground field is a bad idea, I think that windows ust can't redraw smoothly the new positions of that much forms. You can try this by yourself to see I move 100 System.Windows.Forms.Form objects around my desktop using the following code:
Public Class frmMain
Private Sub frmMain_KeyDown(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs) Handles Me.KeyDown
Select Case e.KeyCode
Case Keys.W
For Each frmHero As System.Windows.Forms.Form In Me.OwnedForms
frmHero.Left += 5
frmHero.Top += 5
Next
Case Keys.C
Dim frmHer As New System.Windows.Forms.Form
frmHer.Show(Me)
frmHer.FormBorderStyle = Windows.Forms.FormBorderStyle.None
frmHer.BackColor = Color.Red
frmHer.Size = New Size(5, 5)
Me.Focus()
Me.Text = Me.OwnedForms.Count
End Select
End Sub
If you try this code on any machine You'll see that you can move smoothly about 100 objects(windows forms) or little more depending on the PC. Is it possible that the bad performance of my collision detect system is hidden somewhere in this characteristic of Windows OS(I use windows Vista Ultimate SP1 and Windows XP professional SP2)? I thought to try C++ with DirectX, but I still don't have money to buy these products. I heard that DirectX is optimized for game programming.
|
|
|
|
|
O.G.I. wrote: the moving objects I use are actually windows forms
Yikes! I think that's the heaviest control you could have used. Truthfully, I wouldn't have used anything in the ToolBox, but instead went with either drawing everything myself, or gone with the XNA framework.
O.G.I. wrote: I suspect that using windows forms as units in the playground field is a bad idea
Yep - it is!
O.G.I. wrote: You can try this by yourself
I don't have to. I KNOW it's a really bad idea. Since you just created a small form, removing the borders and titlebar, along with just about everything else, you've essentially made a very heavy-weight Panel control.
O.G.I. wrote: I thought to try C++ with DirectX, but I still don't have money to buy these products. I heard that DirectX is optimized for game programming.
You don't need C++ and DirectX. And, BTW, the DirectX SDK is free and you can pickup the Visual C++ Express Edition for free, here[^].
If I were you, with little experience, I'd start with the XNA Game Studio[^]. It uses C#, but is not that hard to learn if you know VB.NET already.
|
|
|
|
|
|
Wouldn't it be a lot more efficient to actually test each pair of objects for a possible overlap (based on their shapes and coordinates), rather than dealing with 81 million pixels? You can further optimize by:
- sorting the objects to some criterium, say the leftmost x-coordinate
- have a rectangular outline for initial tests; and only when those overlap do a more elaborate test taking actual shape into account.
- not testing pairs of non-moving objects.
It may take a slightly more complex piece of code, but it will be worth it.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Is there a way to bypass the form_load event of vb.net windows application?
and instead it calls a particular function instead.
Rgds,
Rains
|
|
|
|
|
Do you actually need to bypass the calling of the Load-method, or do you want to execute your function instead? 'Real' bypassing is harder, but if you only want to replace the things that get executed during "Load" with an other function then this would suffice;
Form1_Load(object sender, EventArgs e)
{
MyMethod();
return;
InitializeComponent();
DoOtherStuffThatDoesntGetExecuted();
}
I are troll
|
|
|
|
|
yes I want to bypass the load method. As the exe needs to be called from 2 places.
one is through VB5 application i.e. calling a function in vb5 application and the other if it runs itself.
|
|
|
|
|
In that case you'll want to know who started the application, before deciding that you're going to skip the rest of the form_load .
Form1_Load(object sender, EventArgs e)
{
if (StartedFromVB5)
{
return;
}
}
You might add a parameter to the launch of the executable when running it from VB5. You could use this parameter to decide whether or not to skip the load method.
Good luck
I are troll
|
|
|
|
|
Thanks.
one more question. how can you call a vb.net exe from vb5?
|
|
|
|
|
Yup, that's possible. Works just like calling an ordinary executable.
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
This works in VB6, can't give any guarantees for VB5 though.
I are troll
|
|
|
|
|