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.
Related
If I put the blocks showed in the picture in a while-loop everything fail, fo example the stop button does not working!
Someone could explain to me how use events correctly?
thanks
Also try to avoid coercion dots (small red dots near some blocks like add) the data type is changed dynamically (I32 to double) but it is not efficient and the convention in LabVIEW is to change the data type mostly manually.
You have not connected the timeout terminal.
How it always waits for an event and will not allow you to stop the loop. As it does not iterate, it waits.
To stop the loop you should specify Stop button Event, so your loop will iterate upon clicking on stop and you will be able to stop it. OR you can just specify timeout let say 100 ms and Loop will iterate on timeout case once every 100ms, even there is no event.
The other answers tell you how to patch your code so that your current architecture continues working. But that architecture is fundamentally flawed if your application gets larger -- you're going to waste lots of CPU redrawing needlessly and you're going to end up with lags in your UI. A proper LV separation of business logic from graphics logic would look like the image shown below. This image is a LV clip from LV 2015, meaning if you save the image to disk and then drop it directly onto LV 2015 or later, the code will just drop directly. Sorry, I don't have an earlier version of LV with me at the moment so I can't give you a clip for a previous version, but the code below should work all the way back to LV 6.1 (circa 2001a.d.) if you recode it.
EDIT: I realized that I didn't tag this properly - I should have included vb.net as a tag, on the grounds that there could be a code based solution. Note, that no changes to the resolution are made in my source code.
UPDATE: When the program starts execution, the left coordinate for each PictureBox is multiplied by ~0.376, whilst the top coordinate for each PictureBox.Top is multiplied by ~0.418 . This "down-scaling" applies to all picture boxes. The source code I have is incredibly rudimentary and cannot be responsible for this. I also looked at another project and I still face the same error. A simple but poor fix would be to divide each coordinate by the corresponding values mentioned above.
In order to show you the issue I'm facing, please look at the images below. Compare this image, where each PictureBox (i.e. a snake, set of arrows, etc.) has been placed so that they line up with a feature of the background image:
To this image, where the PictureBox elements are bunched together. Their positions have been "down-scaled" closer to the origin of the form (note that all the elements are transforming horizontally during runtime, which is why the elements are in the top right corner):
In the solution I was given (developed in VS 2010 I believe), the position of each PictureBox goes beyond the background image as shown:
It is clear that each picture box has been placed in an organized fashion. During execution, each PictureBox goes to it's intended position (i.e. lines up appropriately with the background image).
Obviously, the original developer of the solution I was given would have not faced the problem I am. The fact that the solution works properly during runtime indicates some kind of error with my instance(s) of VB. Does anyone know of any solutions?
I've came across this question which asks how to change the default resolution for a Windows 8 App and this question which asks why some applications appear differently on different machines, but they pose no clear solutions. I would appreciate any help, since it's holding me back from critical work I must do. Thank you in advance!
I feel a little silly now - I started carrying out a bit more research on VB forms and came came across this Microsoft documentation on form scaling. Realizing that my issue may have been caused by having this scaling automatically carried out, I then found the AutoScaleMode property of my form and changed it from Font to None, which resolved my problem.
I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED
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.