I need to drag and drop 'virtual files' from a wxWidgets application to windows explorer. This codeproject article is an excellent description and demonstration of how to do in MFC. It is not at all clear to me how to use the wxWidgets classes ( wxDataObject, wxTextDataObject, wxDropSource, wxDropTarget, wxTextDropTarget, wxFileDropTarget ) to do the same thing. Can anyone give me some hints on how to proceed?
Motivation: I need to drag and drop files that are located on a remote device. Pulling them from the device and reformatting them as required takes many seconds - minutes if many files are selected. The delay makes the drag and drop completely unusable if the files are downloaded and reformatted when the drag starts but before the drop. Using a virtual file allows the drop to be completed, and only then are the files copied - this makes the drag'n'drop smooth and familiar to the user.
Here is a related stackoverflow question - but it is for MFC and I need a wxWidgets solution.
So, I tried following the codeproject example and specializing COleDataSource. However, when I include afxole.h the compiler complains
Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
This does not look hopeful.
My thought now is I am going to have to use IDataObject. Does that seem reasonable? Can someone point me to a gentle introduction to using this?
Related
I'm working in a VB.NET application using Visual Studio 2017.
I'm using a lot of images in my project and if I follow the instructions that I've found in the Internet (add images to a resource file) the executable ends up weighting more than 300MB. This is a huge problem because when I want to send updates to the users they have to download every time 300MB instead of just a few KB, and perhaps some additional images.
I would prefer the images to be stored separately from the executable, in the same folder, but this does not seem to be possible because using the resource file and building a release version they all get eaten inside the executable.
(Note that I need the images to show while working on the designer module, so it is not an option to load them all through code using image.fromfile, which would do exactly what I want)
Can someone point me in the right direction? Thanks a lot in advance.
You can create a separate class library project in the same solution. A class library project is compiled to a DLL. Include the image resources in this library project and add it as project reference to the main project.
If the image resources don't change, you don't need to re-distribute this DLL.
A trick that could enable you to use these resources at design time could be to use satellite assemblies for culture specific resources (I never tried it so). In your case you would have only on single culture.
See:
Locating and Using Resources for a Specific Culture (MSDN)
Localizing a Windows Application with Satellite Assemblies (article uses C# but should be the same procedure for VB).
How to Localize Windows Forms and Change the Language at Runtime
Hi guys I'm starting the design of a new little game engine and I was assuming the game engine as a DLL and then build a project for the game that would use this DLL and output an EXE file.
But then I read about the latest ID Tech Game Engines and how they do it the other way around. (http://fabiensanglard.net/doom3/index.php)
It's not really explained why though. I have the feeling it has something to do with modding as only the Game (DLL in this case) was open to the public for quite some time while the Engine (EXE) was closed source.
But I would like to know if there are other reasons for this.
As fas as I know the DLL project should have all the reusable code. The normal project should be the application, which would reference the reusable DLL. This way you can build a framework in the DLL project that can be used for any of other future projects.
The other only reason I can think of is that AFAIK only the name of the DLL is recorded in the program file, no text or data so if the Game is potentially bigger than the Engine, it could make the executable size smaller.
[EDIT]
I have thought of another reason to have it this way: The Engine is an EXE so it could be that it could be used without a Game DLL? Like for tools such as CAD or scripting?
If you are using a library in an application e.g. a game, then you have an app with an EXE with zero or more of its own DLLs consuming a library with one or more DLLs.
If you have a generic environment loading elements that customize it's behavior, thus making it a specific game, then you have an environment with an EXE and zero or more DLLs which uses configuration to load various DLLs and configuration files to determine its behaviour.
Either easy, you should probably have more than two assemblies in your application.
E.g. one (the EXE) for loading the main config and modules and connecting them all, one for the main UI, one for the graphics, one for the physics, one for the AI and etc.
I come from a Mac background. I developed games with Xcode and Objective-C frameworks.
Recently I moved to Windows and decided to use VB.NET for a while. It is cool.
Here is my intention:
I want to develop a Windows platform game. The game is rather complex, and I will need some kind of "engine" or "editor" to be able to edit my levels and properties easily. The idea is that I can build most of the game with this editor and then the editor will compile the project files and resources into one .exe file for gaming.
Fortunately, I was able to create my editor with VB.NET. I am able to edit levels and such. However, I am not sure about the "compilation" part to create a .exe file and play the game.
Basically I am at the point of designing the "Compile" button in my editor. But I am clueless. I could not find much documentation regarding this topic.
My editor has all variables and information the game needs to run.
I assume that this .exe file is like another VB.NET project (produced by my editor) that will basically take the data it comes with and "run" the game loop alright.
Any ideas, links, etc? Thanks.
**Note: my game is a 2d game with, probably, a vast amount of sprites and such.
Visual Studio is a fantastic IDE for development of Windows apps. Compiling the project is pretty simple. You just compile and it gives you an exe that's in the .NET Framework. Microsoft also has XNA Game Studio to help with game design if you want to look at gaming frameworks for .NET.
Also, you can take files from your editor if they generate vb.net and use the vbc compiler command to compile them into libraries, executables, whatever you like. The command could be something like this:
vbc /reference:Microsoft.VisualBasic.dll File.vb
Here's a link to the .NET command line compiler for VB.NET.
I'm not entirely sure what you mean here. Are you saying that you have an editor (something like a level or map editor?) for your game, and that you want the output of this editor to be embedded into the exe for your actual game application when it compiles?
If that's the case (or something similar to it) then you'll first want to consider how to persist your data to file. Then you could manually add files you've created as embedded resources. Or better yet, create a file type that holds as many 'levels' or 'maps' as you need and embed that. This way as you create more they will just get added to that file and you won't have to keep adding more embedded resources.
I'm trying to run a program written by someone else in LabVIEW. The program records voltage. However it won't open because it is missing subVIs.
Initially I thought that only one was missing and the rest weren't working becuase they were attached to it but after someone on this forum kindly found it for me the rest of the VIs still won't work so I think I need to download them again. However there are too many off them to get separately, also I tried googling them to no avail.
The subVIs are : Magnet Id, Hardware check, Plot Data and Print, Make Plot Lables, Plot it, Relabel It, Write File header, Record Analog Info, Fix Column Heading, Make Igor Label etc etc (this is not a complete list).
I feel that I should download a DAQ from The National Instruments Website but I am not sure which one. I am using 64 bit LabVIEW 2010 on Windows. Can someone please help me pick out the correct driver?
Thanks!
Just going from memory, those aren't NI VIs that I recognize, especially if the misspellings are in the original.
What hardware is this interfacing with?
You should still be able to open the main VI. It will not compile or run, since the subVIs are missing, but you should be able to open it and maybe get some clues about what it's doing.
The SubVIs all appear to be in the llb file so they should be available. I'm not sure how you can access the subVIs directly from the llb file so you may want to convert this to a project folder (this is the new way of creating libraries since version 8 I think). There are some pages on the NI website that may help, try Converting an LLB to a Project Library and then add this Project Library to your project.
From what I can see the VIs make use of the VISA drivers to communicate with the individual instruments so you should make sure you have this installed. You don't mention what version of LabVIEW 2010 you have but I think they should be provided even the Basic version, I know they are provided with the Professional Development System version.
Can someone point me to the correct place to start development of a twain scanning appliation for the MAC osx. I have done some simple objective c development in the past, but nothing interfacing with a device.
If you're talking about Objective-C and TWAIN on the Mac, this page on the twain.org site has a DMG you can download which contains a sample project called TWAINClientCocoa.
It's from 2002 or something so it requires a little finagling to get it to load and build (rename the .pbproj folder to be a .xcode folder so it will open in Xcode and then do an "upgrade" when you're in Xcode) but it works (just tried it last week) and should give you a good starting point. It relies on the concept of the TWAIN source providing its on GUI but that's something you could modify.
If someone if still interested in this, I have just written a TWAIN client on macOS for my application. This documentation is quite helpful.
The main problem doing this today is that the PicHandle returned by native transfer mode requires some deprecated functions to operate on. On my system (10.13) I can workaround this by making up the headers for those functions but they might be removed totally some time in the future. It's probably worth trying to use memory transfer mode which is more complex.