I've been building a library to interact with one of my databases at work and everything is working fine. But when I open a new script and begin to use the library, it always freaks out when I try to use query expressions on the database. They work when I send them to F# interactive but the intellisense fails, drawing red lines under everything. Why is this? I would like my own dll to be the only thing a user would need to reference for a script.
System.Data.Linq is a reference in my dll file and I've set its Copy Local property to True to no avail. Other than that I haven't the faintest clue of what could be wrong.
What you're showing in the screenshot is evidently an F# script (an .fsx file). Since the code that tries to access the table is in the script file, it is the script file that needs a reference to System.Data.Linq. The fact that your AIXSupport.dll library has the reference does not help: references do not "transfer" like that.
Simply add this one at the beginning of the script:
#r "System.Data.Linq"
Related
I've been successful in using form.location.resx files to localize the strings associated with form controls. However, I don't see how to (safely!) add strings to the .resx file(s) and then access them for such things as message boxes.
If I try to add a string to the .resx file using Visual Studio (2017), I get a warning dialog pop-up telling me that this could corrupt the "project item" (form) or my changes could be lost if I change the associated form.
Also, if I use this method, would I need to manually add my strings to each language file separately?
Alternatively, I could create a bunch of Labels to the form with visible=false and then edit their strings in the .resx files and use something like:
msgbox(LabelSampleMessage.text,MsgBoxStyle.Information,LabelSampleMessage2.text)
But that seems like it would be massively inefficient.
For Windows Forms, the best way to do this is to go into the Designer and set the Language property on the form. This will create a formName.Designer.languagecode.resx file for you. Then you just edit the Text properties of the controls. The changes will go to the resx file for the language you're editing. You can even have different layout and control spacing for each language (useful if a label is short in English but translates to something long in German).
For MessageBox messages, you do the same thing with the Resources.resx file. Just put all the messages in your Resources and duplicate the resx file for each language. Then use the Resource editor to translate the message in the other languages. You can then look up the message using My.Resources.Default.SomeMessageKey
#David: Note that I'm the author of a commercial ".resx" localization program for VS (in the interest of full disclosure). Yes, dwilliss is correct, though the names he used are a little off. For Windows forms, you can't manually update the ".resx" files yourself (directly), hence the warning from VS (don't know why they did things this way - go figure). You won't get that warning for strings you put in "Resources.resx" however. Just manually add "Resources.[LangCode].resx" and update it on your own. You have to add the keys yourself (again, no warnings). You can then simply access each string via the static properties seen in the "code-behind" file "Resources.Designer.cs" (one static property exists for each string you add). These are what MSFT calls "strongly typed" resources. If you access, say, "YourApp.Properties.Resources.SomeMessage" for instance (from "Resources.Designer.cs"), it will be returned in whatever language is currently set in "System.Threading.Thread.CurrentThread.CurrentUICulture" (assuming that language's satellite assembly is installed of course). This is all a pain and highly error-prone for other reasons as well, hence the reason I wrote my program (shameless plug but MSFT's way does work, though it's very primitive for handling translation in general - a professional organization relying on an external translator will save a lot of problems and $ in the long run by using a 3rd-party translation program, not mine necessarily though it would be my tool of choice of course, but anything is better than handling it manually).
I am trying to load a dll (it's not my dll) and it's written in C++
There are no exports to my knowledge, but it does what I need it to do once loaded.
assert(package.loadlib(dllfile,'')()
This throws an error, obv, "procedure not found" but the dll is still loaded, and works as intended.
if I call the above function a 2nd time, it crashes the client, so I need a checker of some sort.
my question is, is there a way to verify it's loaded?
In Lua 5.1 when using package.loadlib as the second argument you must specify the name of a function actually exported by the DLL. It is not important which, if you only need to force the Windows dynamic linker to load the DLL (that seems your case).
To discover such names you can use DependencyWalker (free tool). Open the DLL using depend.exe and look at the export function list panel (the first column has an E header label). Choose any function and use its name as the second argument (If it really doesn't have exported functions you are out of luck!). Try to choose a function labeled as C (not C++). C++ exported functions have mangled names that could cause problems.
For example, say you want to load kernel32.dll: using depend.exe you can discover that among all the exported functions there is one named AddAtomA (but any other C function would do). So you could use package.loadlib in this way:
assert( package.loadlib( "kernel32.dll", "AddAtomA" ) )
The assert call ensures that if the DLL cannot be loaded an error is issued.
To verify a DLL is actually loaded you can use ProcessExplorer (another free tool).
Make sure your script is running (you can put an io.read() statement in a suitable place to keep your script from terminating),
then open ProcessExplorer window,
select the process relative to your script (probably some lua.exe, but you can drag the "target" tool on ProcessExplorer toolbar to your script window to discover it)
and type ctrl-D.
A lower panel should appear showing all the DLLs that the selected process is using. Browse the list to see if your DLL is listed.
Hope this helps.
Ì have had this problem in a number of projects and I have almost given up. I am sure there is a solution though. When I insert a Flash object in a VB.Net Windows Forms application, it works fine for a little while and then I see this error in the Design Screen. I am using Visual Studio 2010
Could not load file or assembly 'Interop.ShockwaveFlashObjects, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I have read several descriptions of why this happens, and apparently it has something to do with strong naming (or lack thereof), but have not found a solution yet. I used Add Reference->COM->Shockwave Flash (C:\Windows\SysWOW64\Macromed\Flash\Flash32_11_2_202_235.ocx) If I ignore the error it appears to work fine, but I don't want my users to have a problem.
I know I can use a browser control and play the Flash in that, but for reasons I won't get into, I have to use a Flash control. Any ideas would help.
Okay. I can't promise this to work for you, but it worked for me.
First, you have to locate a file on your computer titled AxImp.exe. You have to run it from the command prompt. This file is located (for me at least) here:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64
Once you do find and run it, you have to point it to the correct Flash.ocx file you're using, like so:
AxImp.exe <path>\Flash.ocx
Once you've done that you should end up with 2 DLL files in the same directory as the .ocx file. One called AxShockwaveFlashObjects.dll and another called ShockwaveFlashObjects.dll.
You don't care about ShockwaveFlashObjects.dll, just AxShockwaveFlashObjects.dll.
Grab that file and the Flash*.ocx file and paste them into the project directory.
Then include them into your references. This should open up two new references, AxShockwaveObjects and ShockwaveObjects.
Make sure you're Using both of them.
After this, you have to register the Flash*.ocx using RegSvr32 from your command prompt (make sure to run CMD in admin mode). That is done like so:
C:\RegSvr32 <path>\Flash.ocx
This worked for me. I was having the exact same problem (which is what led me here). It could be a half backed hack workaround but for now, that's how it worked for me.
Let me know if it works for you or not.
Hope it goes well for you.
I know this is an old post but I had this issue yesterday and the solution, at least in my case, was very simple. All I had to do was to change the Platform and Platform Target to x86 (Build tab of project property).
I have a visual studio solution written using VB.net.
The solution contains 4 projects.
A GUI
A Service
A Settings library
A WiX Setup project
Here's how it used to work.
Last week, I had no shared settings library, and all was fine. But, because both the GUI and the Service contained an identical class named ConfigXML.vb (for serializing and deserializing settings), which I was regularly making changes to and copying and pasting between projects, I decided to extract the class into a library project of it's own (3 above).
This week, nothing works!
I added project references to 1. and 2. and things do work the same as they ever did. When I "start debugging" I can see and use the GUI as normal.
However, the problem I have is that when I create and install a new Setup of the solution, both the GUI and the Service fail to start.
I presume that the problem is the settings library is no longer where it was expected to be / hasn't been registered properly, needs to be placed in a directory by the Setup.msi or something similar.
This is my first time doing something like this, so I expect it's an obvious fix that I need.
I gather from the name of that class "...XML.vb" that there is an XML file that lives along side this class on disc. If there is such a file, then you need to add that file to the project and then right click on it go to "Properties" and set the "Copy to Output Directory" to "Copy if Newer"
I am maintaining an old VB6 application, and would like to include SQL scripts directly in part of the project. The VB6 application should then extract the text of this script and execute it on the server.
The reasons for this approach are various - among others, we want to deliver only an updated executable rather than a complete update/installation package. Hence, the SQL scripts need to be compiled into the application just like a resource file. And, obviously, one has to be able to get at the content from code, in order to send it to the database server.
Does anyone have a good way to do this?
The simplest solution is to just create a VB module with the scripts as strings.
If you want to use a resource file instead, you can do that too. You can associate a resfile with a VB project (I don't remember how to do this directly in the VB IDE but the VBP file supports a ResFile32 parameter).
EDIT: It seems like the issue here is mostly about formatting -- you don't want to store SQL queries as one long string, but formatting the query nicely inside VB is tedious because you have to add quotes, add string concatenation operators to join the lines together, etc.
I would recommend placing the SQL in a text file and formatting it in whatever way you like. Write a script that will take the text and convert it into a VB module. The build process would be modified to always apply this script first before compiling the application.
For scripting, use your favorite scripting language; if you don't have a favorite scripting language, this is an easy enough task that you could do it in VB, C#, or any other language. If it were me, I'd probably use awk (gawk) or Python.
If you want to use a resource (.RES) to store your SQL, go to the menu:
Add-ins > Add-in Manager...
and select VB 6 Resource Editor. Configure the add-in to be loaded and to load at startup.
From the editor add-in, VB provides a simple interface to add resource strings. You will refer to these using the provided constant values. To load the strings at runtime, use the LoadResString function:
Public Const SQL_INSERT As Integer = 101
Dim strSQL As String
strSQL = LoadResString(SQL_INSERT)
(replace "101" with the constant value of the string you wish to load)
Just another thought on your approach. Because I find myself tweaking the program's behavior or UI for customers I might be in the middle of a change that either is not ready or has not yet been tested and approved. So if I have properties that change from time to time, but I want to maintain control of, for instance connection settings to our ftp server, I will create a resource only dll exposing my properties and use a resource file in the dll to supply the values. When my network manager changes something on the ftp server I change the strings in the resource maanger, recompile the dll and release just the updated dll. I'm sure there are many more solutions, but that is how I do it. If you don't think you might have to change your SQL scripts at the same time you are changing you exe this probably only complicates your work. It has worked well enough for me that now this is pretty much standard for me.