|
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.
|
|
|
|
|
Oh, you mean C, C++, Delphi, PowerBuilder, Java, ...
|
|
|
|
|
|
So learn C++, what do you want, this is a choice you make when designing an application, not when already writing one.
|
|
|
|
|
So you really want to put up with poor contructs and design restrictions to gain code protection? That's all??
You don't have to protect your entire codebase in an application. You really only need to protect business logic and data access. The rest is just UI stuff that really doesn't need protection. If it's that damn critical, you've even have to obfuscate the VB6 code.
Face it, ANY code can be decompiled back to some form that is usable by a hacker. So what if they can't get the VB6 source back, they can still use a C equivilent that a decompiler can output of your VB6 app.
And yes, there are tools out there that will defeat .NET Reflector.
IMHO, what you gain from .NET greatly outweighs the "protection" you get when using VB6.
|
|
|
|
|
I have write following code for encrypt a file. But i don't know how to decrypt that file. Can anybody tell me how should i do that. I have declare a variable named k for store the key that used to encryption
Private k As Byte()
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim infilename As String = "C:\aa.txt"
Dim outfilename As String = "C:\aa1.txt"
Dim infile As FileStream = New FileStream(infilename, FileMode.Open, FileAccess.Read)
Dim outfile As FileStream = New FileStream(outfilename, FileMode.OpenOrCreate, FileAccess.Write)
Dim malg As SymmetricAlgorithm = New RijndaelManaged
malg.GenerateKey()
k = malg.Key
Dim filedata(infile.Length - 1) As Byte
infile.Read(filedata, 0, CType(infile.Length, Integer))
Dim myenc As ICryptoTransform = malg.CreateEncryptor
Dim cryps As CryptoStream = New CryptoStream(outfile, myenc, CryptoStreamMode.Write)
cryps.Write(filedata, 0, filedata.Length)
cryps.Close()
infile.Close()
outfile.Close()
|
|
|
|
|
|
First, this is a repost. I received no answers from my previous query, and I feel it might have been due to my poor explanation of the scenario.
Scenario: I have made an MDI application. My main form has a flowlayoutpanel docked to the left (menu) and a panel docked to the top (header). My menu can be collapsed or expanded off a button click. The reason for this is to allow more content area (workspace) for forms that are loaded. As you know, the default backcolor for a MDI parent is a deep grey, which just looks horrible.
All this functionality works great. The last piece was having a background image on the workspace, which was simple enough. Set a BackgroundImage. This is done with the following code:
Me.BackgroundImage = CType(resources.GetObject("$this.BackgroundImage"), System.Drawing.Image)
Me.BackgroundImageLayout = System.Windows.Forms.ImageLayout.Stretch
Works fine, but when the menu is collapsed, the background image is not redrawn so there appears to be the same image twice by overlapping. The background image is redrawn perfectly when the main application is minimized then maximized, or you move a form over the entire working area that has a backgroundimage and it is magically repainted.
Is there some property or technique needed to force this repaint on any given particular event?
|
|
|
|
|
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. 
