i've installed windows phone SDK and i don't understand why it only give me Windows Phone OS 7 and OS 7.1 since there is 7.5, is that SDK OS or WP OS?
and is it possible to write WP application using VB.NET?
which one better for WP, C# or VB.NET?
I have an Access Data table with three fields (date, tippingB, and precip). I am using dataGridView to view this table and make changes. The third field in the table (precip) is dependent on second field (tippingB). I was wondering if there is a way to use a formula in the field so that when I put a number in the second field, third field automatically gets updated. The last step of the code is updating the access table in the access database (that works so far).
So, my question is if one could use a formula for a column in a dataGridView and also bind it to the dataTable so that when update command is used, the database gets updated.
Interesting thought however, the file also contains a [Runtime] section as well as (possible multiple) [Task.1] and [Data.1] sections (which contain different data and tags depending on the job). If the file was just a CSV file then it would be easy to implement your idea however, in light of the extra data in the file; im not sure how this would work.
You could create a plugin to parse a section; load all plugins at startup, read a section, switch to the plugin that knows how to read/parse that section, and move on to the next one (until you run out of sections).
It'll probably take some experimenting to get it right, but it would allow you to create new plugins when sections change or get added. It should also make it easier to maintain the code in the long-run; you could write even test-scripts for each plugin/section.
We have programs in VB6, VB.Net 2005, 2008 and 2010.
Some of the VB.Net programs were converted from VB6 using the VB.Net converter (Just open the VB6 project).
All this is fine until yesterday.
We uninstalled a program written in VB.2010 via the control panel. Went fine. But now other programs, VB6, VB.Net 2005 and 2008 are having problems. Now have compile errors and reference errors.
We fixed the first. MSFLXGRD.OCX become unregistered (not deleted). Not sure why. We registered it and that fixed some problems.
I am not sure why reference to dlls in other program source bin folders were removed. Adding the reference to these fixed them.
Now in 1 of our 2008 programs we have an Undeclared MSXML2.XMLHTTP in
Dim pXMLHTTPObj As New MSXML2.XMLHTTP
This is on Win 7/64 Pro.
If we open the same programs on another machine from the same folder there are no errors. So probably another unregistered dll. (XP)
This program has a reference to
Microsoft XML, V4.0
which is in the obj\bin\debug folder (it is there) and adding it seems to have fixed that also.
I am now very fearful of uninstalling anything.
Can someone please explain what is happening and how I can safely uninstall????? PLEASE!!!!
It screws up because controls are not registered on a per-application basis. Controls are registered using the COM GUIDs in the controls and the registration is stand-alone. The controls can be used in any application anywhere.
If you have multiple copies of the same control, the control is only registered ONCE since each copy has the same GUIDs and CLSIDs. The filepath to the control is also part of the registration. So, if you have an application that uses the same controls as another application and your installer, when uninstalled, removes the registration details when it removes the controls, the registration data is destroyed for the control no matter how many copies of it are on the machine.
The problem comes down to how your installer is built. The Setup project that comes in Visual Studio is a barebones installer that doesn't have a ton of features in it and can do some pretty stupid things. If you trust it implicitly, without knowing how it's doing things or why, problems like your will come up.
I highly recommend studying Windows Installer technology (specifically Shared Components and reference counting) and using a 3rd party packaging solution, like InstallShield, InnoSetup, Advanced Installer or WiX if you want to avoid situations like this in the future.
Try Save and Close your project, then go out to the project folder and delete the *.SUO files. You'll have to enable viewing hidden files in Explorer to see it. Then reopen your project and see what happens.
In researching this it seems that the problem even exists with the 3rd party installers unless a lot of work is done first.
So if a lot of work must be done why not just do it with the VS.Net Deploy and Setup project, etc. instead of learning another component.
But it is not clear where to look for the proper documentation to know what to do.
We if have a vb.project that has 30 screens with code behind and another 40 or so modules it is a bit tough to know what to do.
Is the solution in the references or the setup dependencies, etc.?
I've seen discussions of have different dlls which is unclear how to do it with the vb components and ocx modules, etc. both for MS VS stuff and also other SDKs, etc that we are using. I don't think that renaming DLLs will work.
So where to begin? What is the best practises for setup and deployment?
This has been causing us nightmares and we are ready to bit the bullet if we knew where the bullet was.
The reason you're in this position is because you don't understand how Windows Installer works. So you're going to have to learn this no matter what.
So if a lot of work must be done why not just do it with the VS.Net Deploy and
Setup project, etc. instead of learning another component.
Because you have no choice. The Deployment and Setup project no longer exists in Visual Studio 11 and it's capabilities are very limited to begin with. You have to use a 3rd party tool, such as InstallShield LE, or InnoSetup, or AdvancedInstaller, ...
Either way, you're looking at a bunch of work to DO IT CORRECTLY IN THE FIRST PLACE!
We if have a vb.project that has 30 screens with code behind and another 40 or
so modules it is a bit tough to know what to do.
The number of forms you have in your application has no bearing on the installer at all. The complicated part comes in when you start referencing external components and libraries. You have to KNOW what you're referencing, how they works and what their installation requirements are.
Coming up with an installer is not just a "OK my app is done now throw an installer together" process. Installers are another program you write SIDE-BY-SIDE with your application so that the installer knows what your app is using and how to correctly install every file, in every component, in every feature, what merge modules are, why they exist and how to use them, ...
I don't think that renaming DLLs will work.
No, it won't.
This has been causing us nightmares and we are ready to bit the bullet if we
knew where the bullet was.
You're writing application in the dark. You have no idea how the components in your app fit together nor how external libraries work, how they are registered or why, and how your installer has to handle these things. If you don't know these things, you can't just throw files anywhere you like and expect everything to work fine.