i'm using SDL1.2 to handle window-management in my openGL framework.
is it possible to destroy a window (surface) while the program is running without calling SDL_Quit()?
background: my framework is really just one gfx component (of potentially many such gfx components) in a multimedia environment. i cannot make any assumptions on what the other components are goind to do (e.g. whether they use SDL). i'm afraid that calling SDL_Quit() will have side-effects on the other components.
currently i'm doing something like:
SDL_Surface m_surface=0;
bool create_window() {
int videoFlags = SDL_OPENGL;
if(m_surface) {
pritnf("window already made\n");
return false;
}
if(SDL_Init(SDL_INIT_VIDEO) < 0 ) {
pritnf("unable to initialize SDLn");
return false;
}
m_surface = SDL_SetVideoMode(WIDTH, HEIGHT, BPP, videoFlags);
return(m_surface!=0);
}
bool destroy_window() {
if(m_surface) {
SDL_Quit();
}
m_surface=0;
}
both create_window() and destroy_window() are supposed to get called multiple times during the life-cycle of the application.
however, it feels weird to call SDL_Init() and SDL_Quit() multiple times.
btw, i'm using linux right now, but i'm targetting cross-platform (at least linux, osx, w32)
I don't think this is possible with SDL 1.2, the screen surface has a special status and only SDL_Quit() can delete it. You can try using SDL_QuitSubSystem() to shutdown only the video part then SDL_InitSubSystem() to reinstate it, but I'm not sure it will work (I can't test this right now).
On the other hand, it looks easy to do with SDL 2.0 with SDL_CreateWindow() and SDL_DestroyWindow().
Either way, you would need to separate initialization (SDL_Init()) from window creation, and cleanup (SDL_Quit()) from window destruction.
Related
I am currently working on selenium using ruby.
Is there any way to focus on a new window from an application?
Thanks!
I'm not aware of Ruby, but this what you can do in JAVA. See if you can implement similar logic in RUBY.
String parentHandle= driver.getWindowHandle();//Return parent window handle
for (String handle : driver.getWindowHandles()) {
driver.switchTo().window(handle);
}
driver.close(); // close newly opened window
driver.switchTo().window(parentHandle); // switch back to the parent window
Unfortunately, I cannot leave comments, or else I would point you to both of these websites:
API examples: http://docs.seleniumhq.org/docs/03_webdriver.jsp -> ruby option
API docs: http://seleniumhq.github.io/selenium/docs/api/rb/Selenium/WebDriver/Window.html
http://seleniumhq.github.io/selenium/docs/api/rb/Selenium/WebDriver/Driver.html
Here is a direct translation of the code by abhijeet in case you are wondering how it may look like in ruby.
parent_handle = driver.window_handle
driver.window_handles.each do |handle|
driver.switch_to.window handle
end
driver.close
driver.switch_to.window(parent_handle)
I'm trying to get a simple OpenGL program going, but I can't get it to display anything. I'm using Swift on a Mac, neither of which I am familiar with, although I've got a good amount of experience with OpenGL on windows. The program runs fine (no GL errors or anything), but nothing displays, until I add this at the end of my openGL initialization:
var vao:GLuint=0;checkGlError();
glGenVertexArrays(1, &vao);checkGlError();
glBindVertexArray(vao);checkGlError();
Then, it gives GL_INVALID_OPERATION as soon as I call glGenVertexArrays(), however the docs don't mention that as an option.
I worried that I might not have a GL3 context (and really I'd prefer to just have a GL1/2 context, however the Swift headers seem to be missing things like glBegin() and glColor3f(), so I decided to settle for GL3), so I tried to manually request one:
required init?(coder: NSCoder) {
super.init(coder: coder);
let attribs=[NSOpenGLPFAOpenGLProfile,NSOpenGLProfileVersion3_2Core,0];
pixelFormat=NSOpenGLPixelFormat(attributes: UnsafePointer<NSOpenGLPixelFormatAttribute>(attribs));
openGLContext=NSOpenGLContext(format: pixelFormat, shareContext: nil);
openGLContext.view=self;
openGLContext.makeCurrentContext();
};
However this didn't seem to affect things at all.
First, glBegin (...) is not valid in a core profile context. You are going to need a legacy (non-core) context for that.
Now, since the legacy context is limited to OpenGL 2.1, it only offers GL_APPLE_vertex_array_object. In a 2.1 context, you can call glGenVertexArraysAPPLE (...) and glBindVertexArrayAPPLE (...) and they will do the same thing.
The problem you are encountering is that on OS X, you link to the same framework regardless which context version you get. That means that you can call functions that are not supported by your context at run-time. Any time you try to use a GL 3.2+ function from the legacy context, you get GL_INVALID_OPERATION.
I was able to solve this by creating a bridging header and including #include in that, then using a GL1 context.
I'm looking to integrate the Barcode2 class in the EDMK 2.6 library into our existing Barcode scanning interface.
I've wired the example code up to our interface method StartScan() and always get E_SCN_READTIMEOUT as the result even though the code seems to be responding to the scan. (the breakpoint at if (scan.Result == Results.SUCCESS) is hit in response to the scan
public void StartScan()
{
if (!barcode.IsScanPending)
{
ScanData scan = barcode.ScanWait(2000); // 2 second timeout
if (scan.Result == Results.SUCCESS)
{
if (scan.IsText)
{
textbox1.Text = scan.Text;
}
}
}
}
The result is always E_SCN_READTIMEOUT, I suspect this may be a conflict with DataWedge 3.4 running on the device, but the functionality of the scanner and triggers seem to be dependent on it.
Getting barcode scans to the clipboard using DataWedge is not an option for us, is there a way to get the library to function despite DataWedge(assuming that is causing the read timeouts)?
The DataWedge application did need to be disabled, (this can be done programmatically via the datawedge API from Motorola, Thanks Abdel for the hint here!).
https://docs.symbol.com/ReleaseNotes/Release%20Notes%20-%20DataWedge_3.3.htm
A little background on our Windows Mobile application for reference, we have a hardware singleton that contains interfaces for all hardware components and loads related types and assemblies via reflection. If we referenced types directly the code above worked.
The end solution ended up being to use the Symbol.Barcode library instead of Symbol.Barcode2.
I know I can control the way Visual Studio handles exceptions according to their type and to the fact that they're eventually caught using the "Exception" dialog.
However, I've got a library that's internally throwing (and catching) an ArgumentOutOfRange exception when I'm calling a specific method. The exception is thrown (and caught by the library) maybe 1% of the time, but I'm calling this method a lot. The editor says it's by design (and indeed, the design they've chosen makes sense).
The thing is that I don't want Visual Studio to break each time the exception is thrown.
I don't want to stop breaking on ArgumentOutOfRange exceptions, as I may have some in my code and want to break on those.
I don't want to enable "just my code" debugging because I'm concerned about the exceptions thrown outside of my code (notably for performance reasons)
Is there a way to achieve this? I've been looking into attributes (such as DebuggerStepThrough), but haven't find something adequate yet.
Any hints on how to do this ?
I don't want to enable "just my code" debugging
Yeah, stop there right now. That is exactly the feature you need to not get the unwanted debugger breaks. If you don't want to know about somebody else's crappy code then flip that checkbox back on.
This invariably goes off the rails when programmers use exceptions for flow control. A very common crime. It takes two of them to turn that into a mess that turns a debugging session into a very tedious click nightmare. When you need the debugger feature that breaks on the first-chance exception then you basically lost if somebody else needed that as well.
Everybody hopes that they can magically use the [DebuggerNonUserCode] or [DebuggerHidden] or [DebuggerStepThrough] attributes to make that problem disappear. It doesn't. The other programmer did not think his code was unimportant enough to deserve those attributes. And, well, it wasn't because there's always a bug hidden in code that uses try/catch-em-all code. Pokémon code.
So Microsoft had to find another way to help programmers deal with crappy library code. They did. Tick that checkbox, bam, solved. Nothing you can do about that crappy code anyway, other than sending a nasty-gram to the author. Don't let us or Microsoft slow you down doing that as well, y'all have to get along to create a product that people like to use.
I think it's not possible in visual studio but it certainly is in WinDbg.
See for example http://blogs.msdn.com/b/alejacma/archive/2009/08/24/managed-debugging-with-windbg-breaking-on-an-exception-part-1.aspx
On a side note it seems that starting with visual studio 2010 you can load and use WinDbg extension DLLs directly providing aditional functionality (including possibly the one that you need) but I haven't tried this yet - see for example http://www.dotnetcurry.com/ShowArticle.aspx?ID=648
What you can do is use Concord, the debug engine that ships with Visual Studio (starting with version 2012). It's quite extensible through a nice managed API (and deployable using vsix technology), but it's not fully documented.
Concord has the concept of debug monitors, that we can hook using the IDkmDebugMonitorExceptionNotification Interface
The cool thing is this interface can monitor all exceptions thrown. It can also "suppress" any detected exception event, which is exactly what we need.
What I suggest is to start with the Hello World sample: . Download it, and make sure it runs as expected for you.
Now, just modify HelloWorld.vsdconfigxml like this:
<!--TODO: If you copy the sample, ensure to regenerate the GUID in this file -->
<!-- 1. change component level to something higher than 40500 -->
<ManagedComponent
ComponentId="51736b11-9fb4-4b6d-8aca-a10a2b7ae768"
ComponentLevel="40501"
AssemblyName="HelloWorld">
<!-- 2. change class full name to HelloWorld.ExceptionHandler, for example -->
<Class Name="HelloWorld.ExceptionHandler">
<Implements>
<InterfaceGroup>
<NoFilter/>
<!-- 3. change supported interface -->
<Interface Name="IDkmDebugMonitorExceptionNotification"/>
</InterfaceGroup>
</Implements>
</Class>
</ManagedComponent>
Then, just create an ExceptionHandler.cs class and put something like this in there:
public class ExceptionHandler : IDkmDebugMonitorExceptionNotification
{
private bool _unhandledDetected;
// we're being called!
public void OnDebugMonitorException(DkmExceptionInformation exception, DkmWorkList workList, DkmEventDescriptorS eventDescriptor)
{
if (_unhandledDetected)
{
// this will cause the program to terminate
eventDescriptor.Suppress();
return;
}
if (exception.ProcessingStage.HasFlag(DkmExceptionProcessingStage.Unhandled))
{
_unhandledDetected = true;
}
else if (exception.ProcessingStage.HasFlag(DkmExceptionProcessingStage.Thrown))
{
if (SuppressException(exception))
{
eventDescriptor.Suppress();
}
}
}
// should we suppress a thrown (1st chance) exception?
private bool SuppressException(DkmExceptionInformation exception)
{
// implement any custom logic in here, for example use the exception's name
if (exception.Name == typeof(ArgumentOutOfRangeException).FullName)
{
// for example, use the module (assembly) name
var clrAddress = (DkmClrInstructionAddress)exception.InstructionAddress;
var clrModule = clrAddress.ModuleInstance;
if (clrModule.Name == "TheUglyOne.dll")
return true; // we don't want this one!
}
return false;
}
}
When you run the project, you should see all exceptions being monitored (regardless of your 'just my code' and/or exception triggers settings), so what you just need to do is implement some logic to suppress the ones you really don't want to see. I've not checked but I suppose you could build your logic using custom attributes as the Dkm classes provide quite a lot of .NET metadata information.
Note: as you can see, there is some trickery to make sure the program will terminate normally.
I have code such that:
[CodedUITest]
public class CodedUITest1
{
[TestMethod]
public void CodedUITestMethod1( )
{
using(var dlg = new MyWinForm( ))
{
dlg.Show();
System.Threading.Thread.Sleep(2000);
this.UIMap.AssertMethod1( );
this.UIMap.RecordedMethod1( );
this.UIMap.AssertMethod2( );
}
}
}
The code was running fine when I manually launched the app(before invoking the test) without the using clause to directly create the control.
I'd like to just use a reference to create an instance of the control and go from there instead of relying on trying to determine a path to the executable and opening it. The app just gets stuck with a ContextSwitchDeadlock.
Is there a way to do coded-Ui tests without doing a process launch? (using the reference and creating the control in the test code) or is there something wrong with the way I'm trying to do it?
It might be possible if you invoke the coded ui test portions (this.UIMap...) on a separate thread. But the way you have it now, they are both on the same thread, so you are going to get deadlocked.