VB.NET OpenFileDialog Latency on Win7 - vb.net

I have a winform, VBExpress 2008 with a single button and this code behind it to illustrate the problem:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
OpenFileDialog1.ShowDialog()
MsgBox(OpenFileDialog1.FileName)
End Sub
When I select a file (in my case small PDF's) I am getting a 3 to 6 second delay after selecting the file until it goes on to the next statement, in this case a MsgBox.
If I repeat selecting that same file a second time, I don't get the delay. But, if I exit the program and re-start it, then I do get the delay again (one time). After the first one hangs it looks like it hangs about ever 7 to 9 tries and the window says "not responding" for a few seconds. I don't have this problem on Vista or XP.
If I select the same file over and over, it might hang the 1st, 2nd and 12th time. Close program try same again, this might be the 1st, 3rd and 9th time. Never the same - as if it is running out of resources and clearing a cache.
I've watched the task manager during the delay and don't see anything unusual coming up. I have a new computer with everything operating properly. I thought maybe it was my Norton Internet Security -- but I turned that off and it made no difference.
Can anyone give me a clue what might be going on and/or how I might trace the source of the delay to the bottom of it? I've tried everything I know to isolate the problem and am running out of ideas. I don't see any other posts about this particular thing.

Project + Properties, Debug tab, tick "Enable unmanaged code debugging". Run your program and select the Output window in VS. Open your dialog. What you see in the Output window are a crapload of unmanaged DLLs getting loaded into your process.
These are the shell extension handlers that are installed on your machine. The bad ones can affect your program in unpleasant ways, much like you describe in your question. Use SysInternals' AutoRuns utility to get control over this. Start by disabling the ones that were not made by Microsoft.

On MSDN suggestion was made to me -- remove network cable and see if problem disappears. It did.
I had two network connections to my old PC which was powered down. Removed those and it resolved the problem.
So, now the question is in vb.net winforms, how do you customize the Win7 OpenFileDialog box (standard win explorer box) to not display or be delayed by dormant network locations? Or, how do you prevent this in Win7. I will research and if necessary re-post that separately.
I really don't want to distribute my application with a warning that if you're on Win7 and have dormant network locations, you're going to get latency when choosing files.

Related

MS Access occassional "Cannot open any more databases" error

I have an MS Access (2013) application with a split database. Everything seems to run smoothly except for occasionally I will get Error 3048: Cannot open any more databases.
The error occurs when the front end tries to run vba code which involves pulling data from the back end and will stall on any line with: Set DB = OpenDatabase() or DoCmd.RunSQL() commands.
The strange thing is that this error seems to be time based. I can access the back end hundreds of times without error if I do it quickly enough but after some time has passed (~1 hr) the error shows up. In fact, I can open the application and leave it running in the background (with no code running) then go back into it after an hour and I will get the error the first time the code tries to open the back end.
I've searched the length and breath of this site and google for solutions so I know this error has been addressed before. To save people reiterating the usual fixes I will list what I've tested for so far with no success:
Recordset limit: I'm not leaving any recordsets open, every time I open one I make sure to close it. The same for the databases. All my requests
to the back end are done via 3 or 4 vba functions and each of these has
a Rec.Close or DB.Close corresponding to every OpenRecordset()
and OpenDatabase() and I never have more than 2 recordsets open at
a time.
Control limit: I have 151 controls on the biggest form in the application so I should be below the limit (I believe this is 245 for a single form?)
Corrupt database: I've copied all my forms and code to a new Access database and run a Compact and Repair.
Machine Issue: I've tested the application on several machines and reproduced the same error.
Anyway with most of the above situations I would expect the application not to run at all, instead of running fine for a set amount of time and then crashing.
Some other points of note:
Citrix Users: The users are split between normal windows machines users who are experiencing this error and others who are using the application through a virtual desktop software (Citrix) who are having no issues. Unfortunately I don't know enough about this virtual desktop to really work out what that implies.
Background vs Foreground: Some users have claimed that the application only crashes if it has been running for a long time AND they switch over to another program and switch back. I've confirmed that simply switching between the application and other programs doesn't cause it to crash but haven't yet been able to leave it running in the foreground long enough to confirm if it crashes without switching between programs.
I've been struggling with this for days, anyone able to help me out?

VB .NET FileSystemWatcher does not fire event on rdp connection

Hy all, I am newbie on this forum and I am italian. First of all I'm sorry for language mistakes; also, reading replies should be after a lot of hours due to different country time.
Configuration: VB .NET 2008 PRO and VB .NET 2008 EXpress
My 2 desktop PC: 1 is WinXP SP3 and 1 is Win7 SP1
Server: Windows 2008 R2 Enterprise
.NET framework: 3.5 SP1
I have developed a WinForms application that runs on server 2008; in the app I use the File System Watcher (FSW) component to receive notification on file deletion for a folder that is on connected PC. Connection is by Remote Desktop (RDP). When users, using the app, deletes a file on this folder (and the app do this work and file on PC is really deleted) I need FSW notify the event. I don't have any error in code, simply FSW doesn't fire the event and so I don't receive any notification from PC. Code for FSW (pasted below) isn't executed. lvwDocFiles is a ListView.
Private Sub fswFiles_Deleted(ByVal sender As Object, ByVal e As System.IO.FileSystemEventArgs) Handles fswFiles.Deleted
Try
lvwDocFiles.Items.RemoveByKey(e.FullPath)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub
FSW is started and runs when users make deletion. Above code runs when users delete a file on local folder (folder on server) so in this case FSW correctly raise the event.
I have seen already the following post (asked 6 years ago):
FileSystemWatcher Fails to access network drive
but is in C# and is different from my situation.
In my mind I think for possible reasons of this:
On PC a specific service must be running? For example I tried to starts Alert service but nothing change
Permissions? But the file has been deleted (the DEL command starts from application on server and correctly arrives on PC)
Notification starts from PC but do not pass through the RDP connection?
Notification does not start on PC? I don't know how to investigate on this and previous point (I need a specific program to do this?)
Any suggestions will be highly appreciated.
Thanks to all
Stefano
I have solved my problem in this way:
- Deleted FSW from the project
- Added 2 custom events, first (FileChangeEvent) will be raised from child form when a file delete occurs in child and communicate this to parent form via a custom eventargs; second (ChildUpdateList) will be raised by parent to communicate to all active childs (all instances of the same form) that one child (not always the same in which delete occurs) must update the list of file in own listview. This is a simple and good solution that controls also the file delete on remote folders (FSW doesn't work on this situation).
Thanks to all that gives me comments and special thanks to Colin Angus MacKay Blog Passing Data Between Forms in which I have found a trace to solve and to Diego Cattaruzza (MVP) Visual-Basic.it (sorry it is in italian) that helps me to greatly simplify the Colin solution.
Stefano

Report Viewer error occurring occasionally

My problem is about report viewer, I didn't know what is the cause of this problem. And it is only occurring occasionally. The problem says something like
Local Report Processing
-----------------------------------
...The process access the file path path\expresion_host_5bc339f79dc24f2fb4b34667e9fadb13.dll
because it is being used by another process
(sorry for not providing complete details, or image, they just chat me this)
but it didn't run, after close the form, i dispose the reportviewer and form, and if re-open it and do it many times, this error will show. And i'm freaking here to solve this, i tried to google it first but none of them help me with this.
by the way, in my workspace, this error is not showing.
but in my boss, this error is showing, maybe because he is using Windows 8.
1.) Application Run As Administrator
2.) When you Close Application at that time use Application.exit at end of code
When a report ( printing ) function is run, a dll ( it is a working temp file generated by application to set a parameter etc.. ) is created in a temp folder for a millisecond and deleted.
At that time if the new antivirus program is catch the file, it also checks and release. and it is locked while it is being checked and your application dump ( the error message ) at that time.
So remove your anti virus you will see problem will be solved. Stopping anti virus may not enough. AV services continue to check every file and blockes.

My.Application StartUp event

I am rewriting an application for printing shipping labels that we have been using for many years, because over those many years, many programmers have added bits and pieces to it, and it has become harder and harder to maintain.
While considering design choices, I came across catching the application's StartUp event in ApplicationEvents.vb, which I thought would be a good choice for this application because the main form is only displayed if there are more than 10 labels to print at a time (displays a progress bar if so, but mostly it does one label at a time and as such the progress bar isn't desired).
Now, whether this is a good choice I'm not sure, but while playing around with it I have found a need to exit the application from this event if certain criteria aren't met (invalid command line args, network directory not found in expected location, and a few other criteria). I have been unsuccessful in figuring out how to exit from the application if something like the above were to occur. The only thing close I have found is setting the StartupEventArgs.Cancel to True, but the documentation states that this only stops the main form from loading and if set to true should point code on a different processing path.
Is there a "proper" way to exit the application in the StartUp event? I've tried using My.Application.Shutdown which doesn't exist, and RaiseEvent ShutDown() which gives the error "Derived classes cannot raise base class events."
Linked here is the main doc I have been using for research (and the related links on the linked page):
https://msdn.microsoft.com/en-us/library/t4zch4d2(VS.80).aspx
You can use End to immediately kill the process, note that:
This will prematurely kill the process
Any files being written to can become corrupted
Any other activity related to the program will be terminated
To protect against file corruption, you could use a subroutine that 'finishes up' and then terminates the program, for example:
Private Sub finishUp()
[..close files, forms, here..]
End
End Sub
I did this myself for a gameserver program I made a couple of months ago; the program needed to note in the SQL database the startup and shutdown times. I made it log the shut-down time in a subroutine similar to the one above.
Note that the same subroutine could (and probably should) be used when you need the program to close at any other time.

ClickOnce performance on a VB.NET application accessing SQL Server DB

I have upgraded a 60 KLOC Windows VB.NET application to VS 2012 and Windows 8.
Everything looked fine, except when I deployed it yesterday to ClickOnce.
The ClickOnce application is incredibly slow to load every form the first time that form is launched, IF the form uses binding. If a form is not using binding (but selecting data from a DB query) they load normally.
The most funny part is that while debugging in VS2012 they load in less then 1 second. When launched from the ClickOnce version they spend more than 60 seconds to load.
If I close one of these forms in the ClickOnce application and re-open it, they load normally in less then 1 second.
It seems that Binding in VS2012 is very bad the first time a form is loaded, but I prefer to think I'm doing something wrong.
Any ideas about this issue?
EDIT 2013/01/18:
After one day cutting unnecessary code, I have arrived to a solution that reproduces the slowness and that has no unnecessary code, so that it will be easier (I hope) to find what is not working proprly in it.
ClickOnce application is here:
http://www.octet.it/Reproduce/
Source files are here:
http://www.octet.it/Reproduce/Reproduce.zip
I can state that slowness is NOT depending on:
SQL Server (I have cut all the code that was accessing SQL server DB).
Binding (there is no binding at all, now).
Development environment: if you run the application from VS2012 it works as expected.
Instruction for reproducing slowness:
Install the ClickOnce application on a Windows 8 machine (mine is
x64, I had not a x86 to test).
Start Task Manager.
Start the "Reproduce" application.
When the MDI form has loaded, hit [Return] key (this will fire a MDIChild form).
Have a look at task Manager, showing how the "Reproduce" app will saturate one of the CPUs of your
machine and occupy about 650 MB of your RAM.
After about 45-60 seconds a MDIChild form will appear.
Close the MDIChild form.
Hit [Return] again and see the MDIChild appearing almost istantly and Task Manager showing no CPU saturation or RAM increases
As I told, before Win 8 the MDIChild (with binding and SQL acces to various tables) appeared in about 2-3 seconds.
Source files are not so interesting to see: they will just show a MDIparent form calling a MDIChild form, but I have included them in the .ZIP file if you want to do some experiments.
MANY thanks in advance for your time.
Let me know what I can do to solve this problem. Any suggestions is welcome.
How are you compiling the application? Are you targeting mixed platforms? Try targeting x86. I had a similar issue that was resolved by targeting x86 when I compiled, which should work fine on your x64 box unless you have some crazy x64 dependencies in your application. Note that this will change the clickonce manifest, which is a headache, but I'm curious if this fixes your issue.