Is it valid to use HBITMAP after calling FreeLibrary? - gdi

I have a case where I need to load bitmap from a resource dll and release handle to it. The update mechanism may update the dll, and having it open will fail overwriting it.
So lets say I have something like this:
HINSTANCE hInst = LoadLibraryEx(resourceDll, NULL, LOAD_LIBRARY_AS_DATAFILE);
HBITMAP hBitmap = LoadBitmap(hInst, "some.bmp")
FreeLibrary(hInst);
is it valid to use hBitmap after calling FreeLibrary ?
Thanks in advance.

Yes, it's valid to release the DLL.
LoadBitmap does the equivalent of CreateCompatibleBitmap, which creates a new bitmap for your process. The bitmap image is initialized with the data from the DLLs resource. That is, the pixel information is copied to the bitmap. The bitmap does not hold a pointer to the resource data. Once created, you can release the DLL.

Related

How to save locally user data in AS3, and then read it/export it?

Hey there, i was wondering what the AS3 experts would do to perform this task: save user data (registry form) locally, and then be able to read it or export it into something client can read.
Thanks in advance, i am quite new to the AS3 approach to this things, thing to notice is this project is pure AS3, and deployed in Adobe AIR, so no server programming.
you can save data in SharedObject to make it readable from flash.
if you need to export it to a user defined location you can use FileReference.save() method, but to read it back the user must enter the path to file manually
If you have access to AIR features, you can save large amounts of data in a file:
var storage:File = File.applicationStorageDirectory.resolvePath("data.xml");
var stream:FileStream = new FileStream();
stream.open(storage, FileMode.WRITE);
stream.writeSomething //there are various .writeXXX functions
stream.close();
I would save xml file (just to avoid inventing custom parser), then read it back.
Depending on the size of your data, you could use a SharedObject to save your data locally.
As for something the client can read , can you be more specific?

Finding a 3rd party QWidget with injected code & QWidget::find(hwnd)

I have a Qt Dll wich I inject into a third-party Application using windows detours library:
if(!DetourCreateProcessWithDll( Path, NULL, NULL, NULL, TRUE,
CREATE_DEFAULT_ERROR_MODE | CREATE_SUSPENDED, NULL, NULL,
&si, &pi, "C:\\Program Files\\Microsoft Research\\Detours Express 2.1\\bin\\detoured.dll",
"C:\\Users\\Dave\\Documents\\Visual Studio 2008\\Projects\\XOR\\Debug\\XOR.dll", NULL))
and then I set a system-wide hook to intercept window creation:
HHOOK h_hook = ::SetWindowsHookEx(WH_CBT, (HOOKPROC)CBTProc, Status::getInstance()->getXORInstance(), 0);
Where XOR is my programs name, and Status::getInstance() is a Singleton where I keep globals.
In my CBTProc callback, I want to intercept all windows that are QWidgets:
HWND hwnd= FindWindow(L"QWidget", NULL);
which works well, since I get a corresponding HWND (I checked with Spy++)
Then, I want to get a pointer to the QWidget, so I can use its functions:
QWidget* q = QWidget::find(hwnd);
but here's the problem, the returned pointer is always 0. Am I not injecting my code into the process properly? Or am I not using QWidget::find() as I should?
Thanks,
Dave
EDIT:If i change the QWidget::find() function to an exported function of my DLL, after setting the hooks (so I can set and catch a breakpoint), QWidgetPrivate::mapper is NULL.
Answered:
Stupid mistake, I was compiling in Debug, so it was QtGui4d.dll and QtCore4d.dll that where loading, not QtCore4.dll and QtGui.dll
Compare the addresses of `QWidgetPrivate::mapper in the DLL and in your code. Esp. if one is linked statically, there might be two instance of it, each with it's own, disjoint, set of widgets.

AS3 Memory Conservation (Loaders/BitmapDatas/Bitmaps/Sprites)

I'm working on reducing the memory requirements of my AS3 app. I understand that once there are no remaining references to an object, it is flagged as being a candidate for garbage collection.
Is it even worth it to try to remove references to Loaders that are no longer actively in use? My first thought is that it is not worth it.
Here's why:
My Sprites need perpetual references to the Bitmaps they display (since the Sprites are always visible in my app). So, the Bitmaps cannot be garbage collected. The Bitmaps rely upon BitmapData objects for their data, so we can't get rid of them. (Up until this point it's all pretty straightforward).
Here's where I'm unsure of what's going on:
Does a BitmapData have a reference to the data loaded by the Loader? In other words, is BitmapData essentially just a wrapper that has a reference to loader.content, or is the data copied from loader.content to BitmapData?
If a reference is maintained, then I don't get anything by garbage collecting my loaders...
Thoughts?
Using AMF a bit with third party products has lead me to believe the Loader class attempts to instantiate a new class of the given content type (in this case it would be a Bitmap class instance). You are probably constructing a new BitmapData object from your Bitmap instance. From that I would assume that the Loader instance references the Bitmap instance, and in your case your code also references the Bitmap instance. Unless at some point you are calling BitmapData.clone().
There are also a couple of ways to force GC. Force Garbage Collection in AS3?
You may find it useful to attach some arbitrarily large object to something, then force the GC to see if that thing is getting cleaned up or floating around. If you are using Windows something like procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) is more helpful than task manager for doing this kind of external inspection.
This of course is a bit trial and error but for lack of something like Visual VM (https://visualvm.dev.java.net/) we are kind of screwed in the Flash world.
It's a good question, but to the best of my knowledge, the answer is no -- neither Bitmap nor BitmapData objects possess references to the loaders that load them, so you can safely use them without concern for their preventing your Loaders from being collected.
If you want to make absolutely sure, though, use the clone() method of the BitmapData class:
clone()
Returns a new BitmapData object that
is a clone of the original instance
with an exact copy of the contained
bitmap.
For example:
private function onCreationComplete():void
{
var urlRequest:URLRequest = new URLRequest("MyPhoto.jpg");
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loader_complete, false, 0, true);
loader.load(urlRequest);
}
private function loader_complete(event:Event):void
{
var img1:Image = new Image();
img1.source = Bitmap(event.target.content);
addChild(img1);
var img2:Image = new Image();
img2.source = new Bitmap(event.target.content.bitmapData.clone());
addChild(img2);
}
Here, img1's source is a Bitmap cast explicitly from the BitmapData object returned by the loader. (If you examine the references in FlexBuilder, you'll see they are identical.) But img2's source is a clone -- new bunch of bytes, new object, new reference.
Hope that helps explain things. The more likely culprits responsible for keeping objects from being garbage collected, though, are usually event handlers. That's why I set the useWeakReference flag (see above) when setting up my listeners, pretty much exclusively, unless I have good reason not to:
useWeakReference:Boolean (default =
false) — Determines whether the
reference to the listener is strong or
weak. A strong reference (the default)
prevents your listener from being
garbage-collected. A weak reference
does not.
you may set a variable in the complete listener that stores the bitmap and then destroy the object later
public function COMPLETEListener(e:Event){
myBitmap = e.target.loader.content;
}
public function destroy(){
if(myBitmap is Bitmap){
myBitmap.bitmapData.dispose();
}
}
works fine for me load some big image and see the difference in the taskmanager

FileReference.save() duplicates ByteArray

I've encountered a memory problem using FileReference.save(). My Flash application generates of a lot of data in real-time and needs to save this data to a local file. As I understand, Flash 10 (as opposed to AIR) does not support streaming to a file. But, what's even worse is that FileReference.save() duplicates all the data before saving it. I was looking for a workaround to this doubled memory usage and thought about the following approach:
What if I pass a custom subclass of ByteArray as an argument to FileReference.save(), where this ByteArray subclass would override all read*() methods. The overridden read*() methods would wait for a piece of data to be generated by my application, return this piece of data and immediately remove it from the memory. I know how much data will be generated, so I could also override length/bytesAvailable methods.
Would it be possible? Could you give me some hint how to do it? I've created a subclass of ByteArray, registered an alias for it, passed an instance of this subclass to FileReference.save(), but somehow FileReference.save() seems to treat it just as it was a ByteArray instance and doesn't call any of my overridden methods...
Thanks a lot for any help!
It's not something I've tried before, but can you try sending the data out to a php application that would handle saving the ByteArray to the server, much like saving an image to the server, so then you'd use URLLoader.data instead, using something like this:
http://www.zedia.net/2008/sending-bytearray-and-variables-to-server-side-script-at-the-same-time/
It's an interesting idea. Perhaps to start you should just add traces in your extended ByteArray to see how the FileReference#save() functions internally.
If it has some kind of
while( originalByteArray.bytesAvailable )
writeToSaveBuffer( originalByteArray.readByte() );
functionality the overrides could just truncate the original buffer on every read like you say, something like:
override function readByte() : uint {
var b : uint = super.readByte();
// Truncate the bytes (assuming bytesAvailable = length - removedBytes)
length = length - bytesAvailable;
return b;
}
On the other hand, if this now works I guess the original byte array would not be available afterwards in the application anymore.
(i havn't tested this myself, truncating might require more work than the example)

Compact Framework - Get Storage Card Serial Number

Morning all,
How would I go about getting the serial number of the storage/sd card on my mobile device? I am using C#.Net 2.0 on the Compact Framework V2.0.
Thanks.
The Smart Device Framework provides a mechanism to get SD Card serial numbers and manufacturer IDs.
I'm not on a machine that I can get the syntax for you but I believe you can use the System.IO namespace to get IO based attributes.
First get a DirectoryInfo to the storage card. (I'm not 100% on the code here, you may need to test, I'll update it if I can get to my machine)
public DirectoryInfo GetStorageCard() {
DirectoryInfo deviceRoot = new DirectoryInfo("/");
foreach (DirectoryInfo dir in deviceRoot.GetDirectories())
if (dir.Attributes == FileAttributes.Directory & dir.Attributes = FileAttributes.Temporary)
return dir;
}
Then check all the properties on the DirectoryInfo that code returns. Thanks to the joys of debugging you should be able to see if the serial number is one of the available properties.
If not, you may need to look to something a bit more unmanaged.
Hope this helps.
You need to use some unmanaged APIs. Specifically, DeviceIoControl using a 'control code' of IOCT_DISK_GET_STORAGEID. This will, in turn, return a STORAGE_IDENTIFICATION structure.
Here's where it gets a bit tricky, as STORAGE_IDENTIFICATION uses a property (dwSerialNumOffset) to specify the (memory) offset from the beginning of the structure, which would be difficult to translate into interop calls.
Edit: Found a VB.NET implementation on the MSDN forums

Resources