Vertex Array Objcects - glGenVertexArrays GL_INVALID_OPERATION on OSX - macos

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.

Related

Exported Adobe Animate User-Interface Components, behave weirdly in the IntelliJ IDEA

I've exported some of the User-Interface components inside of the Adobe Animate into a .swc file to be used at runtime:
public class Main extends Sprite {
public function Main() {
var checkbox:CheckBox = new CheckBox(); // fl.controls.CheckBox
checkbox.label = "Row";
addChild(checkbox);
}
}
It's working nice with the Adobe Flash Builder; but using the IntelliJ IDEA, that I do need to go with, only behaves weirdly sometimes, and argues in unexpected ways of:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at fl.controls::CheckBox/drawLayout()
at fl.controls::LabelButton/draw()
at fl.core::UIComponent/callLaterDispatcher()
or sometimes, argues with the following message (with a fl.controls.NumericStepper in the following example):
TypeError: Error #2007: Parameter child must be non-null.
at flash.display::DisplayObjectContainer/addChildAt()
at fl.controls::BaseButton/drawBackground()
at fl.controls::BaseButton/draw()
at fl.core::UIComponent/drawNow()
at fl.controls::NumericStepper/drawLayout()
at fl.controls::NumericStepper/draw()
at fl.core::UIComponent/callLaterDispatcher()
for the really no rational reason!! I've been searching for solutions (and even reasons!) for many hours and tried what I could've thought of! (e.g: I put the routine in an Event.ADDED_TO_STAGE handler; I tested multiple combinations of the components for the exported file, and I do use the latest versions of the applications and the SDK.)
Please shed some lights on this as it randomly appears with identical code just for the fun of annoyment!! I appreciate any feedback as I'm totally out of ideas!
Thank you in advance :)

ICDevice not ready

I'm trying to write a simple Cocoa App to scan some documents from my USB-scanner. I use it the same way as this example of apple: https://developer.apple.com/library/mac/samplecode/ScannerBrowser/Listings/AppController_m.html
The 'deviceBrowser:didAddDevice...' method is called. There I set the scanners delegate to self (like in the example), but the methods 'deviceDidBecomeReady' or 'scannerDeviceDidBecomeAvailable' are never called.
Is there anything I have forgotten?
Here is the code:
http://pastebin.com/NHZ0j5ze
Oh... reading the .h-files of the frameworks should still be the first option. The order was wrong and I forgot didOpenSessionWithError.
Here is the working code:
http://pastebin.com/NDEY5S13

Motorola MC65 - EMDK .NET 2.6 - E_SCN_READTIMEOUT using ScanWait()

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.

closing an SDL-window without quitting SDL

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.

Is there a way to prevent Visual Studio from breaking on exceptions in a specific method?

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.

Resources