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
Related
Never have known if this is even possible - and if so - how?!!
But I have our MFC applications separated out into the exe project, and a set of associated resource-only .dll projects, one per translation.
We only need to maintain English, and then parse the resources using a 3rd party translation suite to extract translatable strings, get them translated, and then constitute a translated resource .dll project for shipping.
It's a neat coherent system but for the fact that I cannot use MSVC's built-in MFC editors to connect up visual interfaces back to the correct code in the .exe project files.
If I try to use the resource editor to - e.g. generate an MFC Dialog subclass as the code-behind for a given Dialog resource - then the MSVC environment tries to create such files in the resource .dll project - which is wrong and unhelpful.
Does anyone know of a technique to get a given resource project to say "Hey - all of my code-behind should be in this other project over there?
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 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?
I have a working Windows Forms app (split into an EXE and a few DLLs). Now I've been asked to look at creating another app (MyAppLite) that has only a very small subset of the functionality. Think of it as similar to MS Word Viewer vs. MS Word.
Everything that I need to build MyAppLite is contained in the main solution - essentially I need to use a couple of the WinForms and whatever bits in the DLLs they call into.
What would be the best way to do this?
I was thinking of creating another Project in my solution for MyAppLite, then adding the necessary source files as links (using Add Existing Item > Add As Link in Solution Explorer).
I definitely wouldn't want to maintain 2 copies of the source code.
FYI it's a .NET 2.0 VB app, using VS2008.
You can create a new class library to contain your forms that are common to both projects. Create the new project and copy the forms from the original project into the new class library. Then you can import the class library into both the original project (after removing the original versions of the forms) and the MyAppLite version. If you need to change the forms, change it in the class library and then recompile your applications
You could refactor your project so that it would keep the common functionality in a MyAppCore project, and reference that from both MyApp and MyAppLite. The core dll would contain all the common functionality and take parameters as to what to allow and what to restrict, so the set of features in your lite version is customizable(say you have a customer that reaaaallly wants a preview of a certain feature).