I currently have a program that was written in VS 2010 vb.net and compact framework 3.5 and is running on windows CE 6.0(COMTECH CUWIN 5000). This hardware uses an SDK as well
The program reads from Comm ports on a timer, does calculations, displays on the CE screen then sends a string over a Comm port to another computer.
My program is crashing due to memory full every 8-10 hours or so and I cannot figure out why.
I have tried adding a garbage collector at the end of one of my timer ticks but that has not helped only slowed the problem.
A copy of my solution can be found here if you would like to take a look and figure it out.
https://drive.google.com/file/d/0B3bLK_ChVJk-OUJHeXk0cWJqdU0/view?usp=sharing
This solution was translated from VB6. Also I an new to programming so I have a beginners knowledge base to work from.
Thanks in advance
John
Related
I try to open a labview application for a bench test acquisition coupled to e.bloxx network (GANTNER INSTRUMENTS), it shows me this error
It's the application's model. it can't be used alone
This app worked fine until yesterday. My operating system is windows XP professional.
Any help!
That is not likely to be a LabVIEW error -- the NI errors do not typically use "It's" contractions, especially not without some indication of what "it" is in context. I certainly have not seen that text, nor did I find it in any of the know string files of LabVIEW. I think this is an error specific to your application, so you are unlikely to get any help from Stack Overflow. I recommend that you check with your app vendor/author.
I have an vb.net application I distribute to my analysts – We assign perhaps 100 200MB images at a time. The app sequentially opens the large jpg image using GDI+ and the image is placed in the LOH. I scan each pixel looking for data. - when done I dispose the image and use GC.collect. But this does not clear the LOH, and as a result the LOH keeps increasing until the app crashes. A work around is to chop the assignment into 25 instance chunks, but this is risky as our analysts often do this late at night – perhaps after a beer or 2.
The C# construct is
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce
but there is no GCSettings available in vb.net
My vb.net code is
loadedImage.Dispose()
MasterImage.Dispose()
GC.Collect()
Finalize()
But I cannot find a vb.net method to force the LOH compaction
When done
Can you help?
GCSettings.LargeObjectHeapCompactionMode was added in .NET 4.5.1. It exists in VB.NET as well as C#. You're probably targeting a lower version of the .NET runtime. If you want access to this feature you will need to compile against a framework version of 4.5.1 or higher.
This likely won't solve the underlying problem, however. Your leak may not even be where you think it is. Profiling your application with an allocation profiler is the best way to track down resource leaks. Without a Minimal, Complete, and Verifiable example, it is difficult to guess where your application may be going wrong.
I have an application developed in VB 6.0 and VBA that uses latest Office 32 bit version. But since this application is 32 bit, it does not run on systems where 64 bit Office versions are installed. What is the best strategy I have to adopt to port this application to 64 bit. We have a mandate to use VB.NET and minimal (as much as possible) code modification from VB/VBA to .NET 64 bit. Please suggest the best option I can use so that I can leverage all best practices for this porting.
The answer of #Prof.Falken is fine, and porting to VB.NET may be a good idea for itself, but this does not guarantee that you get easily a 64 bit version of your application. If your .NET port will use 32 bit ActiveX components for which you have no 64 bit replacement, then this won't help. Here are some topics listed to be considered:
http://office.microsoft.com/en-us/word-help/choose-the-32-bit-or-64-bit-version-of-microsoft-office-HA010369476.aspx
In our workplace, systems administration decided not to install 64 bit Office on any of the new 64 bit Windows machines since here are too much applications in use (also from third party vendors) which would run into trouble else. And currently we don't see much benefits for us from the 64 bit Office version nowadays.
Here I found another link which might be interesting for you:
http://www.pcpro.co.uk/news/enterprise/356173/microsoft-warns-users-off-64-bit-office-2010
Depending on what the code looks like, one or both of these may be a good way:
a) Port it to VB.NET, or another language altogether.
b) Keep it in VB6, but replace EVERY place it talks to Office, with a wrapper call. This wrapper call talks to a VB.NET application, which in turn talks to Office.
The upshot of method b, is that it makes is possible to keep all the business logic in the old VB6 program untouched. Whether this is suitable or not depends on what the program looks like, what the programmers are experienced with, and so on. The old VB6 program and the new VB.NET could talk to each other through for instance COM or XML-RPC.
I am porting VB.Net 2 code (VS 2005) to VB.Net 4 (VS 2010). So far things have been going relatively smooth. However, in testing my new ported code, I came across a strange behavior.
In VS 2005 (.Net 2), I have a DataTable filled with data. I then use a DataAdapter to send updates back to the SQL Server. When I perform the SqlClient.SqlDataAdapter.Update() command, it execute in roughly 4 seconds. The same code, on the same table in VS 2010 (.Net 4) runs in 1 Minute 17 Seconds. This is completely unacceptable. However, I have no clue as to why it is happening. The .Update() method is an internal command, not one that I modified in any way. It does not error out, it's just painfully slow.
Anyone have any ideas?
After many months of working directly with Microsoft...a solution/answer was found.
I don't feel so bad because it took six different Microsoft programmers and almost six months of time to discover the answer. Apparently, Visual Studio 2010's IDE behaves significantly different than it's Visual Studio 2005 counterpart. When running an application in the IDE, VS2010's hook into the running executable actually hinders the applications performance considerably. There is a hidden option (not found in the menu structure) to run the application without the debugger attached. The hotkey is CTRL+F5. When the application is run in this mode, our performance issue vanished. It's such a silly and simple answer...but the two things that make me feel better is that VS2005 did not have this issue, the "run w/o debugger" options isn't listed in the menu at all, and it took six Microsoft programmers to determine this was the issue.
So for anyone else that seems to have this same issue...try CTRL+F5. :-)
I would like to hear of the experiences of classic vb developers who migrated their applications to delphi rather than vb.net. How has it worked out? Are you glad or sorry that you didn't move to vb.net?
I am not really a vb developer but rather a Delphi developer who was forced to maintain some vb apps for a while. I tried to migrate one vb app to vb.net and after that experience I never tried it again. I successfully migrated several vb apps to Delphi. It wasn't easy and it became a pain in the lower back to find native Delphi replacements for some of the OCXes that had been used (I will never again rely on a third party library for which I do not have the source code.), but it worked out OK.
But as said above: I am an experienced Delphi developer, so I didn't have to learn Delphi at the same time as migrating a vb app. That certainly made it much easier.
I just spotted this on DelphiFeeds:
Delphi for Visual Basic developers
Help to migrate VB applications (knowledge and skills) to Delphi
I had a good friend who moved from Classic VB to Delphi a while ago (back before .NET). He was really happy with the move.
The company he worked for made applications in VB, and they put together a special team (2 developers) to create Active X controls in Delphi for the rest of the company to use. Additionally, when there was something that they couldn't do in VB then the Delphi team would do it. That was when he was introduced to Delphi.
He said it didn't take long before the Delphi team could prototype applications in Delphi faster then the rest of the development group (he never said how large, but way more then two) could. The company never made the switch to Delphi from VB because someone was under the impression the VB was a better solution despite the evidence that Delphi was more powerful and faster.
A few years are I was working with another student on our placement year. We worked for a very large manufacturing company. One of his projects was to create a classic VB app to interface with multiple cameras on a production line and analyse the data in real time. In classic VB this was a shambles - it took on average 1.5 minutes to process a single frame from a single camera (7 cameras at 24 fps) there was no that he could optimise it.
He eventually took the plunge in to Delphi and re-written that app and works fantastically. I've recently been in contact with a few friends who still work there and his app is been running smoothly for 3 years now.
I've worked in both VB and Delphi, and Delphi is (IMO) much less frustrating/limiting. You should be able to use ActiveX / OCX controls as needed (though I agree w/other comments re: avoiding there where you can, and being sure ot have full source code). Apps we've migrated from VB to Delphi (two) have gone well.
I did try in two instance to migrate from VB to Delphi but unfortunately I had to abort midway in one app as it used a lot of third party ActiveX (most from ComponentOne and a few from CodeJoke). We had to abort midway as we could not find any VCL components having equivalent functionality to the ActiveX used in the project.
It was a nightmare for us. Thank god we aborted midway and switched to C#. It was unbelievable that we could get all the features in .NET component to the ditto!
The app we managed to convert, went well off but we had to get rid of a few features that we had implemented in the original software as they required more work in Delphi.