|
Hello!
I've got a strange problem with the following piece of code:
Public Sub NodeDispl()
Dim objOpenSTAAD
Dim nNodeNo As Integer
Dim nLC As Integer
Dim pdDisps(6) As Double
Set objOpenSTAAD = CreateObject("OpenSTAAD.Output.1")
objOpenSTAAD.SelectSTAADFile "C:\temp\staadtest.std"
objOpenSTAAD.GetNodeDisplacements 7, 101, pdDisps(0)
objOpenSTAAD.CloseSTAADFile
Set objOpenSTAAD = Nothing
End Sub
The code above is used to read the results from a structural analysis program and works fine in VBA using Excel. The results are stored in the variable pdDisps, which is an array.
However, I'm trying to make a stand-alone application using Visual Basic (2008 Express Edition). When inserting a similar piece of code in VB, only the first value is read - instead of an array of values I get one value and the rest of the elements in the array are zero.
1. Is there any logical explanation for this behaviour?
2. If not, is there a way I can implement VBA code into my VB application?
|
|
|
|
|
What does your VB.NET code look like?
|
|
|
|
|
I knew I forgot something....
Here is the similar section of code in VB.net:
Public Sub NodeDispl()
Dim pdDisps(5) As Double
Dim ObjOpenSTAAD = CreateObject("OpenSTAAD.Output.1")
ObjOpenSTAAD.SelectSTAADFile("C:\temp\staadtest.std")
ObjOpenSTAAD.GetNodeDisplacements(7, 101, pdDisps(0))
ObjOpenSTAAD.CloseSTAADFile()
ObjOpenSTAAD = Nothing
End Sub
|
|
|
|
|
OK, since OpenSTAAS is a COM object, I suggest ditching the late binding you're using now and go for early binding instead. Open the project propties and click on the References tab. Add a COM reference for your library (it'll show up in the list somewhere) and in your code, rewrite to this:
Public Sub NodeDispl()
Dim pdDisps(5) As Double
Dim objOpenSTAAD As New OpenSTAAD.Output
objOpenSTAAD.SelectSTAADFile("C:\temp\staadtext.std")
objOpenSTAAD.GetNodeDisplacements(7, 101, pdDisps)
objOpenSTAAD.CloseSTAASFile()
End Sub
The code may not as written, but it'll be close.
|
|
|
|
|
Thanks a lot! Now it all works like expected.
It was as I suspected; a trivial solution to the problem. However, I'm quite new to programming and wasn't even aware of the concept of early/late binding. However, in the example I copied (written in VBA), late binding was used. Just out of curiousity - is there a reason why this is used at all?
|
|
|
|
|
Yes. Sometimes you can use different versions of an object and you don't know which one(s) is/are installed. Since early binding is a bit "version" dependant, if the correct version isn't installed when you run the app, every though some version of the component is installed, your app will fail.
|
|
|
|
|
Hi,
I've run into a major problem. As described earlier, I couldn't figure out how to make my code work in vb.NET, when it worked fine in VBA. That problem was resolved and everything has worked fine until yesterday when suddenly everything stopped working. I think I've managed to isolate the problem, but cannot figure out why it occurs:
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles Button2.Click
Dim Analysis As New OPENSTAADLib.Output
Dim nLC As Integer = 0
Analysis.SelectSTAADFile("c:\temp\PSDesigner\PS-1_Operation.std")
Analysis.AnalyzeStructure("NORWAY")
Analysis.GetLoadCombinationCaseCount(nLC)
MsgBox(nLC)
End Sub
Short explanation:
OPENSTAADLib is an external COM component which I had to reference in order to access. The OPENSTAADLib.Output object is used to run an input file for a structural analysis. The "AnalyzeStructure" command is the actual analysis, whereas the GetLoadCombinationsCaseCount is an example of a function to retrieve information from the results of the analysis.
- Now I get this error message: "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
- I tried putting the functions inside Try blocks, and made them loop back a number of times in order to retry. That helped a little, but it seems to be all random whether it works or not.
- when I start the debugging, I can run the sub once or even twice without problems, but then it won't work any longer.
The exception message says: "External component has thrown an exception". I also have seen the System out of memory exception, even though (according to the windows task manager) the program does not use a lot of resources.
I am still a quite unexperienced programmer and I really don't know how to resolve this or even where to begin look for answers (except her on codeproject, of course).Sondre M
|
|
|
|
|
I know nothing of your component, so I can only guess.
The first thing I'd check would be the validity of the PS-1_Operation.std file.
Next, I'd open Task Manager, turn on some addition columns, like Handles, Threads, User Objects, Memory Peak Working Set, Cand Commit Size. Then I'd watch the app run again, watching those numbers. You CAN run the machine "out of memory" by leaking things like Handles.
I'd also throw the app at a profilers, like ANTS.
It's possible that you're not freeing up or releasing this component properly.
|
|
|
|
|
The file applied is definetely valid. The .std is really only a textfile which I have no problem running using the GUI of the analysis program (STAAD.Pro).
I will try and look more closely into the Task Manager although I'm not quite sure what to look for.
Earlier today I opened up a backup copy of the code from last month, hoping that it would still work, but even if it worked better than the latest version, eventually it too failed. The reason why it failed now and not earlier may be that the program haven't been tested for any long "sessions" - until now. This seems to be the problem.
My prime suspect was really something memory related, which would probably explain why the program failed afted a while (after several runs of the analysis). But then I started a blank VB project with the few lines of code as displayed in the previous post, and it failed at once.
How can I make sure that I free up or release the component?
|
|
|
|
|
Only the docs on the component are going to tell you that.
If it failed the first time you ran a small test app, it's probably not going to be resource related. It's probably going to be something wrong with the component itself. If that's the case, there's nothing you can do about it, short of seeing if there is an upgraded version available.
|
|
|
|
|
|
Not really true. You can still install and use the VB6 runtime on Windows 7, even SP1. It doesn't have to ship with Windows 7 in order to work. Windows 7 still has support built into it to keep the VB6 runtime working.
All support to use the VB6 runtime, and therefore run any VB6 app, will end with Windows 7. That means, when Windows 8 shows up, your VB6 app will no longer work at all.
Frankly, IMHO, there is no excuse for continuing to use VB6 as a development platform. All existing applications that still need to be used should be rewritten using C# or VB.NET.
|
|
|
|
|
C# and VB.net applications can easily be decompiled. Is there any way to protect the application made in .net from decompilation.
gold
|
|
|
|
|
there are obfustication tools available to hide your code. DotFusticator Community edition is bundled with Visual Studio. As wit all such tools, some are free, and will stop the casual code thief, after that you pay for what you get.
|
|
|
|
|
I don't know the specifics, as far as I remember VB6 runtime should be included with weven / 7 / windows vista whatever the hell it is now, but they have said it is a dead, unsupported language. Time to port to .net my friend.
|
|
|
|
|
EliottA wrote: whatever the hell
I like it 
|
|
|
|
|
VB6 is rubbish. Why on earth would you still be using it ? It's been a dead language for almost a decade.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Christian Graus wrote: VB6 is rubbish
You've probably not used VB6 in your life.
|
|
|
|
|
Sadly, I have. And Microsoft agrees with me, that's why they killed it. VB.NET was going to be a lot LESS like VB6, before all the VB6 retards jumped up and down. They knew it was beyond redemption and set out to start again.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Microsoft made a good decision to start everything from scratch. Apart from the basic language syntax, everything is different in VB.NET, adding to this was the unhelpful MSDN which made the transition for VB6 programmers a really tough one. That is why many programmers were reluctant to switch over to VB.NET (and consequently to .NET)
Despite all this, IMHO, I still feel that VB6 was not bad enough to be called "rubbish". If you consider pre-.NET era alone, you would appreciate why I made this point.
|
|
|
|
|
VB6 was only ever useful for people who wrote apps in a very narrow band, and for people who could make up the shortfall by using C++ COM dlls to do the real work.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Shameel wrote: That is why many programmers were reluctant to switch over to VB.NET (and consequently to .NET)
No, not really. The switch was never made because businesses didn't want to spend the money on rewriting apps that were already written in VB6 and worked.
Shameel wrote: Despite all this, IMHO, I still feel that VB6 was not bad enough to be called "rubbish". If you consider pre-.NET era alone, you would appreciate why I made this point
Yeah, it's still garbage because it used error handling constructs that were 15 years old at the time, had very limited support OOP concepts, terrible interoperability support with native functions of Win32 and third party libraries, and limited support with everything else "Windows".
|
|
|
|
|
Yes, he has, as so have I. It is garbage compared to .NET.
|
|
|
|
|
Dave Kreskowiak wrote: It is garbage compared to .NET.
I wouldn't agree with you although I admit that it was a lot "less" than .NET that a comparison itself is not warranted.
But most people will agree with me that in the pre-.NET era, we did not have many choice as far as RAD tools were concerned.
|
|
|
|
|
Shameel wrote: But most people will agree with me that in the pre-.NET era, we did not have many choice as far as RAD tools were concerned.
Yes, pre .NET the basic choice was RAD or real programming.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
VB6 will stop working from Windows 7 SP1. Is this Correct. According to some sites microsoft has planned to stop the shiping of vb6 runtime from Windows 7 SP1. 
