I'm knee deep in my second Firemonkey app for Windows and OSX and slowly converting my library of functions to handle cross platform issues. I am trying to create a generic SelectDirectory function that will run platform specific code for Windows or OSX. I have SelectDirectory working great for both platforms called individually, but the Windows specific one requires a hwndparent handle to run.
This is being run in a IFDEF MSWINDOWS directive (just as the OSX one is in its compiler directive). How can I pass a generic handle to this function or how can I reference Application.MainForm or something that can be cast into a Windows handle inside this function? I am hoping to avoid using Firemonkey specific units in the uses clause of this library. I would rather pass in a THandle somehow and cast it into a TWindowHandle inside the function, but after an hour of working on it, I don't see how to do it without compromising the usefulness of my library.
Any help appreciated.
Use WindowHandleToPlatform to get the Windows-specific TWinWindowHandle which has the Wnd property. This is the native window handle (HWND).
Related
I have a dot net dll which uses System.Drawing.dll for using classes like Bitmap, Rectangle,Size etc.. But my dll cannot be used on xamarin... Plz suggest me what else should I use in my dot net dll for using Bitmap etc.so that it can run on xamarin.
Your dot net dll is complied for specified platform, such as Windows. so you cannot use it in other phone OS. It is no way for you to directly use dll in Xamarin unless you build it for portable class. But portable class is a generic class base, it lack of lots of classes. Such as Bitmap, it is different in different OS like Nick Turner said, so you will failed to build your source file.
The best way, you can reuse some none-platform dependent code in you dll, but for others, you need to write new code in each Android, ios, winphone project. So the Xamarin is not so wonderful for writing once, using every where. There is still lots of work in Xamarin, especially for platform specific code.
I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
I see that there's a Nuget Platform implementation for the following
Win32 - SQLite.Net.Platform.Win32 XamarinIOS -
SQLite.Net.Platform.XamarinIOS XamarinAndroid -
SQLite.Net.Platform.XamarinAndroid
But is there one availabe for Mac / OSX?
I'm developing using the Xamarin Studio and wish to eventually write a Mac app too, but to start with I want to write NUnit tests on the Mac and therefore I believe that I need a Mac version?
Unfortunately I have not had time to create any more platform implementations.
That said, they are fairly easy to do, you should be able to basically reuse the Win32 class implementation.
The one change you will have to do is to include a Mac/OS X compatible binary of sqlite and change the DllImport statements so that they actually reference that file instead.
The Win32 platform implementation also does some fancy stuff to dynamically load the correct 32/64-bit version of the sqlite binary, using a Win32 function called LoadLibrary.
I'm not sure how this would work of OS X, but I guess there would be an equivalent function you can pinvoke. If you don't want to mess with that just reference the 64- (or 32-) bit sqlite binary directly and make sure the tests run as the same.
If you do go through with this I would love to see a pull request on github:)
I was just thinking. C# has Winforms/WPF, Java has Swing and other frameworks, C++ has QT and so on; is it possible to create an application without using a Framework?
Putting aside the practicality of it, I'm just curious. How would one create an application that Just Works(tm) without needing external frameworks?
Two options come to mind:
Classical Win32 applications written in C. I don't know if standard Windows SDK API also counts as an "external framework" in your book, but that's as low as it gets.
DirectX/OpenGL games written from scratch with your own homebrew framework (not external, right?) There you get to do all the drawing yourself - although again, you use a pretty big library of primitive drawing functions.
If you want even less "framework", you'll have to code your own OS and drivers. :P
C# needs .NET Framework, not WinForms (which is an optional library used by some application). The same with Java.
Unmanaged (native) applications usually use some runtime library - the library of common functions. You can write a native application without any library - the compiler lets you do this, but you will need to (re)write lots of common functions, eg. for string manipulation etc..
Firstly, what is a framework?
Really a framework is just a bunch of code that is provided to you. You could, at least in theory, write the same code yourself. In that case you wouldn't be using a framework.
Your application can only do what the operating system allows it to do. Your program cannot directly manipulate the graphics card for example. So you have to use the APIs of your operating system in order to do anything.
So you are going to be calling into other code. (unless you write your own operating system). You will also being using another framework or api to get stuff done.
Yes. How: in the way that the frameworks you mentioned are implemented.
From a Windows point of view, you would register your window with Windows, then listen to window messages and react as required. Everything would be up to you - from drawing the window to building controls.
I'm completely new to COBOL, but I'd like to take a look at the different options for GUI programming on Windows. I don't really like Tcl/Tk, though. Is there some resource for developing a Windows GUI in COBOL in the same manner that one would develop a GUI in C?
Thanks!
I used MicroFocus version 2.0 and it supported creating Windows GUI forms with an event driven model. They are now on version 5.1. Although the full version is quite expensive, there is a book with a stripped down learning version here:
http://www.murach.com/books/mcb2/microfocus.htm
check out http://www.netcobol.com/
in particular http://www.netcobol.com/products/windows/cobol.htm
For OpenCOBOL, there is an embedded Tcl/Tk layer by Rildo Pragana (author of TinyCOBOL, his TC Tcl/Tk sample compiled and linked for OpenCOBOL, first try), but if you don't like Tcl/Tk, his toolkit places almost all of the GUI on the Tk side, so:
There is also a GTK+ layer sample
Source code looking like:
*> Add a text entry field
CALL "CBL_OC_GTK_ENTRY_NEW"
returning gtk-textentry
END-CALL
*> Connect code to the text entry, passing the entry widget
SET callback TO ENTRY "CBL_OC_activate"
CALL "CBL_OC_G_SIGNAL_CONNECT"
using by value gtk-textentry
by reference "activate" & x"00"
by value callback
by value gtk-textentry
END-CALL
...
*> window is ready to show
CALL "CBL_OC_GTK_WIDGET_SHOW"
using by value gtk-window
END-CALL
*> Start up the event loop, control returned when GTK main exits
CALL "CBL_OC_GTK_MAIN" END-CALL
*> Something terminated the GTK main loop, sys-close or bye or
display "ending..." end-display
FLTK worked, but I haven't posted the trial source codes.
GtkHTML widgets worked too.
A Gambas COBOL GUI layer is hosted on Google Code
ROOT/CINT can interpret OpenCOBOL generated C, and then you can get interactive graphs from WORKING-STORAGE.
Qt tested fine, but C++ requires more, albeit thin, wrapper source, so GTK was targeted instead.
Pretty much anything that can be wrapped by C, can be called by OpenCOBOL. That includes the native Microsoft WinAPI.
While working on the FAQ I found that using Vala really opens up the field for extending COBOL. As both OpenCOBOL and Vala produce intermediate C, the mixing potential is nearly unlimited, and developers can benefit from efforts by either project. I recommend checking out Vala for use from COBOL.
See the OpenCOBOL FAQ, section 5 for working samples. Screen capture image from source code listed at http://opencobol.add1tocobol.com/#does-opencobol-support-the-gimp-toolkit-gtk