According to this page (and several others) you need to create a dummy window, then a dummy legacy context, then use wglCreateContextAttribsARB to create a modern context.
However I tried using the old way with wglCreateContext and loading functions manually:
glCreateShader = wglGetProcAddress("glCreateShader");
glShaderSource = wglGetProcAddress("glShaderSource");
glCompileShader = wglGetProcAddress("glCompileShader");
...etc for all other functions that I need
Then I checked the context version:
int minor;
int major;
glGetIntegerv(GL_MAJOR_VERSION, &major);
glGetIntegerv(GL_MINOR_VERSION, &minor);
printf("%d.%d\n", major, minor);
And I got "4.6". Why isn't the version something like 2.0 and why is the fake context thing needed?
If you are willing to limit your application to never using WGL extensions (ie: you can't do things like control vsync, use more advanced pixel formats, create robust or debug OpenGL contexts, or any number of other tools) and always using a compatibility context, then yes, you can get away with not using the more modern context creation APIs. But there's no reason to impose such limits on your program.
Related
This example code manually reads a bitmap file, uses CreateDIBSection() to make GDI allocate memory for it, and create an hbitmap handle. Then it uses a MemoryDC to draw the bitmap to a window DC:
ftp://ftp.oreilly.com/examples/9781572319950/cd_contents/Chap15/DibSect/DibSect.c
hdc = BeginPaint (hwnd, &ps) ;
...
hdcMem = CreateCompatibleDC (hdc) ;
Why can't we use GetDC() with NULL or with hwndDesktop instead? Why can't we cache the device context instead of repeatedly creating it?
If the machine has only one display device and we are only drawing to windows why do we need to constantly harmonize bitmaps and device contexts? Once the pixeldata is copied to the buffer provided by GDI, does GDI update it when that HBITMAP is loaded into a DC and drawn on? If the user also wishes to draw on it is it necessary to synchronize access? (By calling GDIFlush() first?)
It's hard to figure this out when most all of the object properties are opaque and abstracted. I've read almost all of the related MSDN, a lot of Petzold's book, and some articles:
Display Device Contexts
CreateCompatibleDC()
CreateDIBSection()
Memory Device Contexts
Guide to Win32 Memory DC
Guide to WIN32 Paint for Intermediates
Programming Windows®, Fifth Edition
Edit:
I think my question boils down to this:
Is a device context a TYPE of display or is it an INSTANCE of graphical data that is able to be displayed. A computer typically has only a handful of displays but it could have hundreds of things to display on them.
GetDC(NULL) is the screen HDC and the screen is a shared resource, therefore you should only do read/query operations on this HDC. Writing to this HDC is not a good idea on Vista and higher because of the DWM.
Since a HDC can only contain one bitmap, one brush and one pen, Windows/applications obviously need more than one HDC provided by the graphics engine.
You can count on CreateCompatibleDC to be relatively cheap operation and I believe Windows has a cache of DCs it can hand out. If you are creating a game/animation type application you might want to cache some of these graphic objects on your own but a normal application should not.
You don't generally call GDIFlush unless you are sharing GDI objects across several threads. You can use SetDIBits if you want to mix raw pixel bytes access and GDI.
I don't really get the once screen argument, Windows has supported multiple monitors since Windows 98 and there is not much you can do to prevent the user from connecting another monitor.
I think your problem is that you are getting hung up on Microsoft's names for things, Microsoft's name "device context" and the names for calls like "CreateCompatibleDC".
"Device Context" is a bad name. The Win32 documentation will tell you that a device context is a data structure for storing the state of a particular device used for rendering graphics commands. This is only partially true. Look at the different kinds of DCs that exist: (1) screen device contexts, (2) printer device contexts, (3) the device context used by a bitmap in memory, and (4) metafile device contexts. Of these only (1) or (2) are actually doing exactly what the documentation claims they are doing. In the other cases device contexts serve as a target for drawing calls but not as containers for the state of some physical device. (This is really noticeably true in the case of metafile DC's: metafiles were an old Win32 thing that basically just cache the GDI calls going in to them to be replayed later, kind of a crude vector format.)
In a hypothetical object oriented programming version of Win32, device contexts could be instances of some class that implements an interface that exposes graphics drawing calls. A better name for such a class would be something like "Graphics" and indeed in GDI+ this is what the analogous construct is actually called. When we "Create" -- via CreateDC, CreateCompatibleDC, etc. -- we create one of these objects. When we GetDC we grab such an object that already exists.
To answer your questions:
Is a device context a TYPE of display or is it an INSTANCE of graphical data that is able to be displayed. ?
They are in so sense types of displays. You can think of them as instances of a class of objects with private implementations that expose a public interface exposing drawing commands.
Why can't we use GetDC() with NULL or with hwndDesktop instead?
You can't use GetDC(NULL) as the device context into which you are going to select an in memory bitmap because in such a situation you need to create a device context that does not already exist; GetDC(NULL) is like a singleton instance that is already in use.
So instead you usually CreateCompatibleDC(NULL) or CreateCompatibleDC(hdcScreen). Again CreateCompatibleDC(...) is a confusing name. Imagine the hypothetical object-oriented version of what is going on here. Say there is an IGraphics interface that is implemented by RasterGraphics, PrinterGraphics, and MetafileGraphics. Imagine the "RasterGraphics" class is used for both the screen and for in memory bitmaps. Then CreateCompatibleDC(...) would be would be like a factory call Graphics.CreateFrom(IGraphics g) that return a new instance of the same concrete type with perhaps some state variables initialized.
Why can't we cache the device context instead of repeatedly creating it?
You can. You do not need to delete device contexts across function calls. The only reason people often do is that they are a shared, finite resource and creating them is cheap. I think actually that they used to be very limited under old versions of Windows so old Win32 programmers tend to not cache them out of muscle memory from the old days, from Windows 95 days.
If the machine has only one display device and we are only drawing to windows why do we need to constantly harmonize bitmaps and device contexts?
Don't think of the "compatible" in CreateCompatibleDC(...) to be about "harmonizing with the screen" think of it as meaning "Okay Windows I want to create one of your graphics interface objects and I want the kind like this one, which is a normal raster graphics one and not for printers or for metafiles."
I know that before we needed to use gdk_threads_enter and gdk_threads_leave but now this functions are deprecated and I'm confused about threads.
Should i just add threads with g_idle_add and that's it?
For workers that are unrelated to UI stuff, use the GThread API, for anything UI related you have to use g_idle_add/g_timeout_add or attach a custom GSource to the desired event loop.
In some cases you'd want to combine those - do some work in a GThread and notify the UI from there - as soon as the worker has finished - via g_idle_add.
If you are developing a library you could also implement it in a very clean and cancelable manner via the GAsyncInitableIface (though that requires a bit more reading before starting to actually implement it).
In response to #ptomato's comment:
You should use gdk_threads_add_idle() and gdk_threads_add_timeout()
instead of g_idle_add() and g_timeout_add() since libraries not under
your control might be using the deprecated GDK locking mechanism. If
you are sure that none of the code in your application and libraries
use the deprecated gdk_threads_enter() or gdk_threads_leave() methods,
then you can safely use g_idle_add() and g_timeout_add().
Use g_thread_new (name, func, data)
I have been searching online for a neat way to compile code at runtime and manipulate the running application's objects (properties etc.). I have come across Snippy, CodeDom and CSharpCodeProvider but I didn't completely understood how I can use those solutions in my application to do what I want.
Bottom line is, I want to have a small portion of the code in an external file so I can swap out different code during run time (e.g. Formulas to manipulate Data and etc.) Could somebody explain to me how exactly can I implement this in a WPF application in a neat fashion? I just need to pass the external code some data and after execution it will return me some data that I can populate an object with.
P.S: I also thought about parsing Mathematical expression from String and manipulate my data that way but if I can parse and execute C# code externally at run time, it will give me much more freedom and control over the formula and data. Thanks in advance.
I think you would do better using .NET compatible dynamic language like IronPython or IronRuby. Those integrate pretty much seamlessly with C#/.NET and are actually designed to provide execution-time scriptability.
Trivial example of IronPython usage from Jon Skeet's C# in Depth:
// the python code
string python = #"
text = 'hello'
output = input + 1
";
// setup the scripting engine
ScriptEngine engine = Python.CreateEngine();
ScriptScope scope = engine.CreateScope();
scope.SetVariable("input", 10);
engine.Execute(python, scope);
// the results
Console.WriteLine(scope.GetVariable("text"));
Console.WriteLine(scope.GetVariable("input"));
Console.WriteLine(scope.GetVariable("output"));
Needless to say, the scripts can use .NET Base Class Library and any extra methods you expose to them.
I would like to make a program (I would prefer in C language) , but even in cocoa , that can take data from an external program (such as iTunes or adium) and will use them. For example i would like to take the data of a listbox or the text of the chat so as to manipulate it. I need a place to start. In windows I think it is possible with some apis that find the hWnd of a window and then find a pointer to the listbox or textbox. Please give me some info on how to start. Thanks you in advance.
It's not clear exactly what you want to do. It's either impossible or severely restricted.
For one thing, different applications use different ways of constructing a “listbox”—Cocoa applications use NSTableView, Carbon applications use DataBrowser, and GTK, Qt, and Java applications use even more different APIs. These do not all go through some common kind of list box thingy; each is an independent implementation.
(You could hope that either NSTableView or DataBrowser would be based on the other, but don't count on it.)
For another, it is impossible to obtain a pointer to that control. You cannot access another application's NSTableView or DataBrowser view or GTK/Qt/Java equivalent unless (and this only works for NSTableView) that application deliberately serves it up to you. It doesn't sound like that's your situation.
The closest you can get to that is Accessibility, which may be pretty close, but is unlikely to work with most applications not based on Cocoa.
Even then, the view may not be showing you all the data. A table view may be lazily populated, and a table view designed in imitation of the iOS UITableView may even never have all the data (because it only has what it can show).
(All of the above applies to every kind of view, not just table views. Collection views, text fields, buttons—same deal for all of them.)
The only way to get at the true, complete copy of the data is to ask the controller that owns it. And, again, that's impossible if the application is not specifically offering it to you. Not to mention, the application might not even have a controller (not object-oriented, not MVC, or just sloppily made).
… so as to manipulate it.
Getting the data in the first place is the easy part. It is nigh-impossible to mess with data in another application—for good reason.
The closest you're going to get to either of these goals is the Accessibility interfaces.
I'm currently using a lot of the same subclassed objects with custom methods. It would be more convenient to create my own library which I can use for several projects.
The goal is to have my own classes being available in the same way classes like UIView, CGRect etc are, including convenient methods like CGRectMake, both with classes and structs. To sum it up, I want to create my own equivalents of:
Classes like UIView
Structs like CGRect
Convenient functions like CGRectMake
Have this available as a library
Have this available as an XCode template, thus, having these custom Objects available as 'new files' in XCode
So basically I'm looking for instructions on how to create classes, structs etc in order to create all the above. What is the best way to do this? The 320 project seems like a good starting point. But it lacks (I think) in:
having the library available in new projects right away
having the new classes available under 'new file'
Even if I would create an own static library, will I be able to release the app on the app store, since linking to 3rd party libraries is not supported on the phone?
For your convenience, these are basically the sub questions, covering the scope of this question:
How can I create my own library for Mac / iPhone development?
How do I create classes, structs and inline function for this library?
How do I create my own Xcode template based on this library?
Will I be able to release iPhone apps using my own static library?
FYI Xcode 3.2 has a new project template called Cocoa Touch Static Library. You might want to go that route.
If you were doing this for a Mac, you'd create a framework. However, you mention UIView, so obviously you're working with the iPhone. Apple doesn't allow iPhone applications to dynamically link against other libraries at runtime, so your only option is to create a static library. A static library is linked into the application executable when it's built.
To my knowledge, there's no static library project template in Xcode. What you'll likely have to do is start with a different iPhone Xcode template and add a Static Library target. Hang on to the default application target; you can use that to build a simple test application to make sure the library actually works.
To actually use the library in an application, you'll need two things: the compiled library (it has a .a extension) and all the header files. In your finished application, you'll link against your static library, and you'll need to #import the header files so that the compiler understands what classes, functions, etc. are available to it. (A common technique is to create one header file that imports all the others. That way, you only need to import a single file in your source files.)
As for creating your own custom templates, there's a simple tutorial here that should get you started: http://www.macresearch.org/custom_xcode_templates You can probably copy the default templates and just customize them to suit your purposes.
The struct syntax looks like this:
typedef struct _MyPoint {
CGFloat x;
CGFloat y;
} MyPoint;
Structs are are declared in header files, so you can (I believe) Command+Double Click on the name of a struct to see how it's declared.
Another little trick for creating structs is to do something like this:
MyPoint aPoint = (MyPoint){ 1.5f, 0.25f };
Because the compiler knows the order of fields in the struct, it can very easily match up the values you provide in the curly braces to the appropriate fields. Of course, it's more convenient to have a function like MyPointMake, so you can write that like this:
MyPoint MyPointMake(CGFloat x, CGFloat y)
return (MyPoint){ x, y };
}
Note that this is a function, not a method, so it lives outside of any #interface or #implementation context. Although I don't think the compiler complains if you define it in an #implementation context.
CGPointMake is defined as what's known as an inline function. You can see the definition for that in the Cocoa header files, too. (The difference between an inline function and a normal function is that the compiler can replace a call to CGPointMake with a copy of CGPointMake, which avoids the overhead of making a function call. It's a pretty minor optimization, but for a function that simple, it makes sense.)
The 320 project is a good example of an iPhone class library. You basically compile your project down into a .a library and then statically link against this in your client projects.
Since this is a community wiki now, I thought it will be helpful to link some resources and tutorials:
http://blog.stormyprods.com/2008/11/using-static-libraries-with-iphone-sdk.html
http://www.clintharris.net/2009/iphone-app-shared-libraries/
Enjoy!
The 320 project seems like a good starting point indeed. But it lacks (I think) in:
having the library available in new projects right away
having the new classes available under 'new file'
Those are project and file templates. For more information, ask the Google.
If you plan on releasing this on the app store, you wont be able to use your library in the way that you would like. As mentioned above, linking to 3rd party libraries is not supported on the phone. I think there is a 'hack' way to make it work, but you'll lose distribution.
The best I could come up with was putting all the relevant code in a directory and sharing it that way. I know its not as elegant, but its their limitation ie. out of our control.