Visual Basic

Shameel1-Dec-09 7:14

1-Dec-09 7:14

EliottA wrote:
whatever the hell

I like it

Christian Graus1-Dec-09 5:29

1-Dec-09 5:29

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.

Shameel1-Dec-09 7:15

1-Dec-09 7:15

Christian Graus wrote:
VB6 is rubbish

You've probably not used VB6 in your life.

Christian Graus1-Dec-09 7:19

1-Dec-09 7:19

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.

Shameel1-Dec-09 7:28

1-Dec-09 7:28

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.

Christian Graus1-Dec-09 7:43

1-Dec-09 7:43

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.

Dave Kreskowiak1-Dec-09 8:36

1-Dec-09 8:36

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".

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Dave Kreskowiak1-Dec-09 7:25

1-Dec-09 7:25

Yes, he has, as so have I. It is garbage compared to .NET.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Shameel1-Dec-09 7:32

1-Dec-09 7:32

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.

Christian Graus1-Dec-09 7:44

1-Dec-09 7:44

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.

Dave Kreskowiak1-Dec-09 8:42

1-Dec-09 8:42

Oh, you mean C, C++, Delphi, PowerBuilder, Java, ...

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

goldenrose91-Dec-09 8:42

goldenrose9

1-Dec-09 8:42

VB6 is not a garbage. vb6 applications cannot be fully & easily decompiled, whereas .NET Applications can be easily decompiled to get the original source code. We have to use some third party expensive Obfustication tools for protecting our code. Although Obfustication does not protect the code completely. Even after Obfustication the code is decompiled.

Source: Google. Confused | :confused:

gold

EliottA1-Dec-09 9:45

1-Dec-09 9:45

So learn C++, what do you want, this is a choice you make when designing an application, not when already writing one.

Check out the CodeProject forum Guidelines[^]
The original soapbox 1.0 is back![^]

Dave Kreskowiak1-Dec-09 10:53

1-Dec-09 10:53

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.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Decryption

Pasan1481-Dec-09 4:12

Pasan148

1-Dec-09 4:12

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()

Re: Decryption

Dave Kreskowiak1-Dec-09 5:44

MDI BackgroundImage drawing issues

1-Dec-09 5:44

A little Google goes a long way: http://www.obviex.com/samples/Encryption.aspx[^]

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

EliottA1-Dec-09 3:22

1-Dec-09 3:22

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?

Check out the CodeProject forum Guidelines[^]
The original soapbox 1.0 is back![^]

Dave Kreskowiak1-Dec-09 4:29

1-Dec-09 4:29

There is no setting to change. IMHO, background images behind MDIChild windows just makes the window look more cluttered, but it's my app...

What I think you're missing is the MdiParent form renders it child windows in a control, just like a Panel control is a container for holding and drawing other controls. That control is called "MdiClient" and it's automatically added to any form that is tagged as an Mdiparent.

Instead of setting the background of the MdiParent form, grab a reference to the MdiClient control by searching the Controls collection of the MdiParent form, then set the BackgroundImage property of the MdiClient instead.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

EliottA1-Dec-09 4:56

1-Dec-09 4:56

I tried the following;

Private Sub frmMenuParent_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    'set the mdiclient bg image
    For Each ctrl As Control In Me.Controls
        If TypeOf (ctrl) Is MdiClient Then
            ctrl.BackgroundImage = Global.snd.guiMainMenu.My.Resources.Resources._VisionMainMenuBackgrnd1024_768
            ctrl.BackgroundImageLayout = ImageLayout.Stretch
        End If
    Next
End Sub

But the background image was still tiled, and not stretched. When I collapsed my menu the same behavior occured, where it seems the background moved instead of being redrawn to stretch the entire container area.

Any ideas?

Check out the CodeProject forum Guidelines[^]
The original soapbox 1.0 is back![^]

Dave Kreskowiak1-Dec-09 5:21

1-Dec-09 5:21

From the documentation on the MdiClient class, it looks like BackgroundImageLayout is not used. Try changing the BackgroundImageLayout of the form instead, but you still have to keep this code that you posted to change the BackgroundImage of the MdiClient control.

As another possible option, you could try the Paint event of the MdiClient control (you'll have to write this up manually) and painting the background image yourself.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

EliottA1-Dec-09 6:09

1-Dec-09 6:09

Well that suggestion definately made the initial drawing stretched, so I thank you on that. But the original issue still stands as when controls are hidden to expand the working area, the image is tiled, overlapped etc showing that it was never redrawn, just moved or nudged.

Dave Kreskowiak wrote:
As another possible option, you could try the Paint event of the MdiClient control (you'll have to write this up manually) and painting the background image yourself.

I thought of this but was reluctant due to a performance hit, if there is no other way I guess I will implement this.

Check out the CodeProject forum Guidelines[^]
The original soapbox 1.0 is back![^]

EliottA8-Dec-09 8:27