Referencing
Console Application은 그런 것이 있다는 정도만 챙기시고
VB.Net의 중심 인터페이스는 Windows Form 이다
실은 또 이것을 나중에 확장되어 .NetFrameWork에 추가된 Windows Presentation Form(WPF)라는
그래픽적인 것을 강하게 특징화하는 인터페이스로 가게 되지만
아직은 여전히 Windows Form이 핵심이다
그러니 VB.Net으로 Windows Form을 만들어가면서 엑셀과 연동하여 이야기를
전개하면서 또 파생적인 토픽을 다루어 가도록 하자
앞 페이지에서 Console Application프로젝트내에서 Windows Form Application으로
쉽게 바꿀수 있음도 보았지만,
크래스를 참조하여 무언가 새로운 프로그래밍을 구성하는 것을 이해하기 위하여
Console Application의 Module시트를 사용하여 Window 프로그래밍을 띄워보자
UNO_Weekly에서 Windows Form의 콘트롤을 외부라이브러리로 참조하여
엑셀의 UserForm에 삽입하여 사용하는 것을 많이 이야기 한다
그러니 UserForm의 파워풀한 원래의 버전인 Windows Form을 해본다고
생각하시면 부담이 적을 것이다
Visual Studio에서 VB.Net으로 무언가를 만들때는
외부라이브러리 참조라는 의미보다는
.Net FrameWork의 수많은 부속품들과 Win32 Components 를 끌어 모아서(Referencing)
조립을 하는 조립장으로 보시는 개념으로 약간 바꿔야 한다
엑셀프로그래밍에서 엑셀이라는 이미 본체 개체가 있고 이 엑셀 본체가 갖고 있는
부속품들을 자동으로 작동하게 하는 작업이고 필요한 경우 가끔 외부라이브러리를
참조하는 것이지만,
VB.Net은 Windows Form 이라는 것 자체도 실은 .Net FrameWork의 것을 끌어다가
사용하는 것이다
한마디로 Module시트 한장 달랑 놓고 시작해도 되는 것이다
Visual Studio 정품에는 Empty Project(템프릿사용하지 않는 빈프로젝트)라는 것이 있어서
이곳에 하나,하나 필요한 모듈,크래스등등을 삽입하여 만들어가도
되지만 Express Version에는 Empty Project라는 템프릿이 안보인다
그냥 Console Application 프로젝트를 만들고, 나타나는 달랑하나 Module시트..
모듈시트는 VBA에 항상 사용하던것이니 낯섫지 않다
이 모듈시트하나에 그냥 Windows Form을 하나 띄워보자
Module Module1
Dim oFrm As System.Windows.Forms.Form
WithEvents oBtn As System.Windows.Forms.Button
Sub main()
oFrm = New System.Windows.Forms.Form()
oBtn = New System.Windows.Forms.Button
oBtn.Text = "My Button"
oBtn.AutoSize = True
oBtn.Font = New Drawing.Font("맑은 고딕", 10)
oBtn.Location = New Drawing.Point(20, 20)
oFrm.Controls.Add(oBtn)
oFrm.Width = 300
oFrm.Height = 300
oFrm.ShowDialog()
End Sub
Private Sub oBtn_Click(sender As Object, e As System.EventArgs) Handles oBtn.Click
MsgBox("I'm going to VB.Net World from small village of VBA")
End Sub
End Module
Console Application를 만들고 Module 시트의 내용을 위와 같이 그대로 입력을 했다면
아래의 그림과 같이 에러가 날 것이다
VB.Net환경에서는 마우스를 에러난 줄에 갖다대면 안내문이 자세하게 나온다
그러니 에러가 나더라도 대책을 쉽게 세울수 있도록 해준다
어떤 개체타입이 정의되지 않았습니다!!! 라는 이야기는 해당 개체를 만들기 위한
크래스화일(라이브러리화일,혹은 어셈브리화일)을 참조하지 않았습니다!! 라는 말과 같다
이 페이지의 제목이 Referencing (참조)이다
VB.Net은 빈탕의 프로젝트에 원하는 크래스라이브러리를 참조시키면서,
조립을 해나가는 것인 것이다
console application 템프릿으로 소루션을 만들었기때문에
Windows Form에 관한 것, 그리고 그래픽에 관한 라이브러리가 필요 없으니까
하나도 이것에 관련된 것이 참조되지 않은 것이다
Window Forms을 만들려면 , Window Forms라이브러리를 참조하여야 한다
그런데 아래와 같이 Windows Form에 관한 것은 에러가 사라졌는데
Font개체에 대한 것은 그대로 있다
이것은 Font개체를 그려주는 일을 하는 개체는 다른 라이브러리가 또 있어야 하는 것..
같은 요령으로 System.Drawing 라이브러리를 참조시키면 모든 에러가 사라진다
아니..이런것을 일일이 죄다 해줘야 하는 것인가??!!
그래서 프로젝트템프릿이라고하는 것이 제공된다
프로젝트를 시작할때
Console Application 대신에 Windows Form템프릿을 사용하게 되면
이런 것들이 자동 참조가 되는 것이다
그리고 코딩하면서 필요한 라이브러리를 또 참조하면 되는 것
여기에서는 일부러 참조를 하면서 개발을 한다는 것을 강조하기 위하여
Console Application을 그대로 사용해 본것이다
VB.Net은 라이브러리 참조가 기본적임을 인식하시게 하기 위함이다
아래의 그림과 같이 VBA와 비교한다면
VBA는 엑셀이던, 워드이던 각 프로그램의 만들어진 개체를 조합하여 원하는 작업을
자동화하는 것이지만,어떻게 자동화하던 엑셀프로그램이다..
VB.Net은 .Net Framework의 개체이던
기존윈도우의 Component들(엑셀도 하나의 Window Component)을
필요한대로 참조하여 전혀 각자의 새로운 소루션을 만드는 것
NameSpace
VBA에서 엑셀의 개체에 접근할때
Worksheets("mySheet").Range("A1").Resize(100,100).Interior.ColorIndex=15
와 같이 하면 Worksheet개체가 갖고 있는 Range개체속의 바탕을 다루는
Interior개체에 접근하여 Interior개체의
ColorIndex속성값을 15로 주었다..
모두 개체이다..
그런데 위에서 아래와 같이 표현식을 사용했다
oFrm = New System.Windows.Forms.Form()
System이라는 개체의 Windows라는 개체의 Forms라는 개체의 Form개체에 접근한 것일까???
아니다..
System,Windows 그리고 Forms는 모두 Name Space라고 한다
개체가 아닌..하나의 구역,공간을 지정한 이름인 것이다
즉 Form이라는 개체는 System이라는 공간속의 Windows라는 공간속의 Forms이라는 공간
개체를 담고 있는 Container역할을 하는 것이다
왜 이런 복잡하게 찾아가는 짓을 하게 할까?
당연하다..대한민국땅에 살면 주소를 대한민국을 사용하지 않아도된다
하지만 세계화가 되고 다루는 영역이 넓어지면
대한민국에 있는 홍길동과 일본에 있는 홍길동은 같은 사람일수 없다
그런 구분이 필요할 만큼 VB.Net에서 다루게 되는 개체들은 수없이 많음을
의미하는 것이다
예를 들면 VBA에서 엑셀을 다룰때는 Application이라는 개체를 생략해도 알아서 한다
엑셀을 위한 VBA동네에서는 엑셀만 사니까..
하지만 VB.Net에서 엑셀라이브러리를 참조하게 되면..
와 같이 NameSpace를 거쳐서 Excel이라는 NameSpace를 거쳐서
Application이라는 엑셀의 최상위개체에 접근할수 있게 되는 것이다
물론 이것도 위에서 이야기한 라이브러리 참조(Referencing Class Library)를 한후
하여야 하는 것이 당연하고..
궁극적으로 이곳에서 이야기 하고자 하는 것은 엑셀과 VB.Net를 섞어서
여러분이 하고자 하는 자동화의 극대화인 것이니까..
아하..엑셀을 이렇게 참조만하면 VBA에서 다루던 엑셀을 마음대로
VB.Net에서 다룰수 있구나!!! 빙고!! 맞았다..그래서 하는 것이다
그러니 할만한 가치가 있고, 미래지향적 사고를 갖었다면 당연 도전하여야 한다
Imports
그런데 위와 같이 길게 주소를 쓴다고 하는 것은 좀 그렇지 않은가..
그래서 Imports라는 키워드가 나타난다
이것은 그림과 같이 모듈시트(크래스모듈이던, 모든 개체 모듈시트)의 모듈시트이름 위에..
Imports 라는 키워드를 치면
현재 참조한 라이브러리 상태에 따라서 모든사용가능한 NameSpace명이 나타나고
이것을 이곳에 작성하면 코딩할때 길게 때려 넣지 않아도 된다, 아래와 같이..
Imports System.Windows.Forms
Module Module1
Dim oFrm As Form
WithEvents oButton As Button
만약 NameSpace를 Imports 하지 않았다면 아래와 같이 하여야 하고
Module Module1
Dim oFrm As System.Windows.Forms.Form
WithEvents oBtn As System.Windows.Forms.Button
어느 것으로 하던 상관없다..
이 코너에서는 될수 있는 한 NameSpace를 Imports하지 않고 할 것이다
왜냐면, 개체의 족보에 익숙하시게 하기 위하여, 하지만 실제 업무에서 코딩은
Imports 하고 하는 것이 원칙이다
NameSpace Alias
NameSpace의 별칭(Alias)라고 하는 편리한 것이 있다
Imports 를 이런 저런 많은 것을 시키다 보면 코딩할때 NameSpace에 대한 것이 헷갈릴수 있다
그래서 NameSpace에 나름대로 별칭을 하나 부여 하면 편리하다
아래와 같이..
Imports Q = System.Windows.Forms
Module Module1
Dim oFrm As Q.Form
Dim oButton As Q.Button
Q라는 별칭으로 System.Windows.Forms 라는 NameSpace를 참조하게 하는 것이다
그러면 코딩할때 Q를 하고 쩜을 찍으면, 좀더 편리하게 해당 NameSpace에 존재하는
개체라이브러리 목록을 쉽게 볼수 있으니까..
Windows Form Loading With Module
이렇게 하여 module시트하나에 Windows.Forms.Form을 참조하여 윈도우폼을 하나
띄워 보았다..
이 화일에서는 Console Solution의 모듈시트의 Sub Main()을 윈도우폼을 띄게 한것
그러니 StartUp Object는 Sub Main으로 한다
Main이라는 프로시져는 프로젝트내에 하나만 있어야 한다
이것을 한 의미는 VB.Net은 Module시트 한장달랑 놓고
이런 ,저런 필요한 라이브러리를 참조하여 만들수 있다는 이야기이고,
실은 제공되는 템프릿을 사용하면 편리하게 많은 잡다한 일을 생략하고 갈수 있는 것
다음 페이지에서 부터는 Windows Application 템프릿을 사용하면서
Windows가 갖고 있는 콘트롤들을 하나, 하나 살펴보도록 하자
***[LOG-IN]***