i use a ListView to display a Selection, when switching through the possibilities with some time between the slections everything works fine, but when I switch fast (less then 1s) it crashes. The error I get is within the file "app.g.i.cs".
Sender is the app, the error is "{"Value does not fall within the expected range."}"
Thank you
(I've already cleaned and rebuild the project, didn't help)
Related
I have an App that I inherited in VB6 and have ported mostly to VB.net
When I compile / run the app - it highlights all the files in the current selected folder.
What makes it worse, is it's very difficult to search online as what search terms does one use?
The app was ported to VS 2005 - quite successfully - but this has me stumped...
I have tried commenting out all the code that's run on startup and it still does it, so it must be some sort of background thing...
Any ideas?
I can't find an old version of my app to see if it's changes I have made and I don't know where to begin. See the image:
The top part is before I run the app, the bottom is once the app is running and has focus. I hope it makes sense
Also, if I'm browsing and then run the app, and go back to the browser, when my app gets the focus again, the webpage goes back to the top...
The folder is just an example - Basically when I compile (or later run) my App, if I go to Windows Explorer - when the app gets focus - whatever folder I am in has all its files highlighted. If instead of going to Windows Explorer, I go to a web browser, when the app gets focus the browser goes to the top (similar to Home).
There is Windows Integratio, but I have commented out what I can and still am no closer.
Does this info help?
I found the problem - after going back to the vb6 project and removing everything except for the 5 modules needed to startup and I eventually tracked the problem.
There was some code being called when two edit boxes received focus which called send keys home and end - hence it would go home - select all files to the end. I had deactivated one of the edit boxes to not receive focus and it helped temporarily(obviously until the other box got focus), but since deactivating the send keys when they get focus has helped. Albeit an arbitrary problem, maybe it will help someone in the future..
I'm new to vb.net and need some help.
I'm not sure what's happening but a deleted main form loads on start up even after setting a new form as start up.
I took a few buttons and copied it on a group container and named it Dial Pad on the old form. After testing to see if it works I adjusted the dimensions and ran again but this time it stayed the same. I clicked on the buttons but nothing happened. Check the code and there was code in it and correct. However there seem to be other set of buttons name as same but with a 1 at end.
I checked the solution explorer and it didn't show, only the originals showed. After frustration I created a new form and copying the code and created new controls. I deleted the old problematic form and set the new one as start up but the old form with the dial pad still appears and only exit button I added and coded works. The datagridview on old forms works as well and is the old way I can get to the other forms which still work.
This problem sometimes indeed occurs. The solution is pretty simple. Go in the menu to Build > Clean Solution and rebuild. Or else, open the context menu on the solution node and select Clean Solution.
Screenshot of the menu:
Screenshot of the solution node context menu:
I had the same problem with a web page in VB. Rebuilding website/solution didn't work for me. The only things that worked were 1. Completely restarting VB or 2. File -> Close Solution and then loading it again File -> Recent Projects and Solution. This one at least spares some time.
I am creating an app for Window 8 using the 'Windows Runtime'.
I have a custom control which does it's own painting. To accomplish this, I am using a Rectangle control and setting it's 'Fill' property to an ImageBrush derived from a SurfaceImageSource and then using an ID2D1RenderTarget to do the painting. For painting bitmaps I am using ID2D1RenderTarget::CreateBitmapFromWicBitmap and am saving the ID2D1Bitmap that is returned. The control is animated and I create and all of the bitmaps that I need and then continuously paint the scene.
This all works well for the most part. However I am finding that on a random basis, suddenly all of the ID2D1Bitmaps that I have squirreled away stop painting anything. I can trace through the code, and there seems to be nothing wrong, but when I call ID2D1RenderTarget::DrawBitmap, nothing happens. I find, however, that if I force the ID2D1Bitmap to be recreated from the file, it then works fine again. It is almost as if the bitmap has been invalidated or something.
This loss of the bitmaps happens very infrequently and appears to be random, but I can pretty much guarantee that it will fail within an hour or so of playing. I am pretty sure that it is not a memory leak because I can run the app for hours at a time without any increase in memory used. Also, if I force the bitmaps to reload, I can then continue on as if nothing had happened.
Can anyone give me a clue as to what might be going on here?
Thanks.
After much trial and error (not helped by the fact that it was VERY difficult to reproduce the problem), I discovered that the root of the problem was that the call to ID2DRenderTarget::BeginDraw was returning DXGI_ERROR_DEVICE_REMOVED. In the example code upon which I based my code, it showed that in response to this error, I needed to re-create the context, which I was doing. However I was not deleting all of the cached bitmaps associated with the old context, and those bitmaps would not work with the new context. I fixed that and now my app recovers from this error.
Although this solves the problem, I am still not sure I understand why I am getting the 'Device Removed' errors at random times while playing. Also, needless to say, that reloading all of the graphics in the middle of playing shows up as a nasty delay glitch. Fortunately it happens rarely, so I guess I will have to live with it.
Is there any benefit of using COINIT_MULTITHREADED in a DirectShow application? For now it has given me some troubles, but I am not sure if using CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) is the right fix for the problems.
The full story:
I have a pretty straightforward web camera capture application with ability to choose the capture source and call the device manufacturer settings through OleCreatePropertyFrame.
My app runs pretty stable, no memory leaks, I can switch between devices without any problems (I completely rebuild DirectShow graph each time when user chooses device).
But there is only one problem after showing the property page of the capture filter. If I just show it and close without changing anything, all continues normally. If I change any setting in the property pages and then close the property frame, also everything continues seemingly normal .. until the next time I change the device and rebuild the graph. The previous graph gets destroyed normally, no errors, filters are being removed and released correctly. And right when I create a new graph and call graphBuilder->SetFiltergraph( pfg ), my app crashes with some weird access violation errors insde of Kernel32. But if I change COINIT_MULTITHREADED to COINIT_APARTMENTTHREADED, this error disappears.
So is that COINIT_MULTITHREADED a real problem of my application or maybe there is some other monster hiding somwhere? Has someone experince with it?
Any thread that creates a window must be STA. Both user32 and gdi are fundamentally thread-unsafe.
Within my Cocoa app, I call NSWorkspace's openFile: method to open some file with its default application.
Sometimes this works just fine, and the other application gets focus, as it should.
But alas, sometimes (the occurrence of which seems to be totally random), after the focus goes briefly to the other application, it goes quickly back to my Cocoa app. This is unwanted.
Any ideas what the causes could be?
Note: I have also tried the openFile:withApplication:andDeactivate:, passing YES to the last argument. This doesn't work either. The strange random occurrences of focus going back to my Cocoa app persist.
I'm unable to reproduce this now. Not sure what the problem was.