최근 PowerBuilder 12로 업그레이드되는 PowerBuilder 9 앱을 지원하기 시작했습니다. PowerBuilder Classic 또는 .NET으로 마이그레이션해야하는지 여부를 파악하려고합니다. . PB.NET을 사용하면 더 많은 유연성을 얻을 수 있지만, 설명서를 읽는 것만으로는 이점이 무엇인지 명확하게 알 수 없습니다. 분명히 WPF 폼을 활용할 수 있었고 Visual Studio Shell을 사용하고 있었지만 변경할 수있는 충분한 이유가 있는지는 알 수 없습니다.Powerbuilder 9 앱을 12로 마이그레이션
좋은 질문, 그리고 사소한 하나. 더하기 측면에서
, 당신은 WPF 컨트롤 및 레이아웃 제어를 얻을. 너무 멀리 떨어져있을 계획이없는 개발자라면 화가에게 내장 된 예쁘고 반짝이는 컨트롤, 스킨 성 및 크기 조정/스케일링을 얻을 수 있습니다. uber-geek의 경우 컨트롤 삽입과 같은 작업을 시작할 수 있습니다 (시간 제한 대화 상자에서 시간이 초과 될 때 기본 동작이 될 카운트 다운 타이머를 나타 내기 위해 컨트롤 버튼 안에 진행률 막대를 생각하십시오)), 비록 여러분과 PB가 여러분의 XML로 멋진 일을하려고 할 때, 저는 여러분이 때때로 서로의 발가락을 밟을지도 모른다고 생각합니다.는 또한, 파워 스크립트뿐만 아니라, 기능의 광대 한 .NET 라이브러리에 쉽게 액세스 할 수 있습니다. 다시 말하지만, 쉽게 진행되는 개발자는 그다지 이점을 얻지 못할 수도 있지만, 화면 대 형식은 SMTP 기능을 앱에 쉽게 구현할 수 있습니다.
아래쪽에서는 PB에서 PB 로의 마이그레이션만큼 원활하지 않은 마이그레이션을 생각할 수 있습니다. 내일 일하는 것이 필요하다면, PB-PB.NET 마이그레이션을 시작하는 것은 아마도 지금가는 길은 아닙니다. 어떤 것은 깨져서 고칠 필요가 있으며, 적어도 모든 크기 조정을 이용하려면 모든 창을 사용해야합니다.
다른 측면은 성능, 특히 앱 시작이었습니다 (그리고 이것은 PB.NET 개발자뿐만 아니라 WPF 개발자들 사이에 공통된 불만이라고 들었습니다). 나는 모든 것이 더 빨리 달릴 것을 기대했지만, 그것이 혼합 된 가방이라는 것을 알았습니다.
다른 한 점 : 최신 PB (작성 시점)은 12.6이며 12.5의 유지 보수 패치입니다. 12.0을 구입하면 무료로 업그레이드 할 수 없습니다. 12.0과 12.5 사이의 점프는 가격이 비싼 업그레이드가 필요한 "주요"릴리스입니다. 어쩌면 너 이 n-1 버전을 원하지만 1250을 목표로 삼아야한다.
행운을 빈다.
@Matt Balent 간접적으로 의견에 또 다른 좋은 점이 제기되었습니다. 숙련 된 PB 개발자라면 PB9에서 PB12로 이동하면서 당일 치기없이 생산성을 높일 수 있습니다. PB.NET으로 이동하는 것은 쉬운 학습 곡선을 수반 할 것입니다. IDE가 크게 다르므로 첫 번째 날 CommandButton의 Default 특성을 설정하는 것조차도 실망 스러울 수 있습니다 (불가능하지는 않지만 첫 번째 작업 인 경우 30 초가 아닌 30 분 계획).
PB.Net에 가면 Visual Studio 2010 셸에서도 멈추게됩니다. SAP에 의해 업그레이드되는 것을 믿지 마십시오. –
나는 PB.Net으로 많은 것을 해본 적이 없다. 그러나 나는 그가 PB9에서 PB12로, 그리고 나서 PB12에서 PB12.NET으로 또는 PB9에서 PB12.NET으로 마이그레이션하는 것이 더 좋을지 궁금합니다. – Slapout
@ Slapout : X에서 Y로 Z로 마이그레이션하는 일반적인 대답은 다음과 같은 질문입니다. 왜 Z에서 해결 될 수있을 때 Y에서 발견 된 버그를 확인하고 해결해야합니까? 나는 당신이 Y에서 확인하고 해결하는 것이 더 쉽다는 이론을 세울 수 있다고 생각한다. (마지막 단계는 PB.NET에서 PB 네이티브 일 때 더 사실일지도 모른다.)하지만 저의 경우는 높은 노력 (비용)으로 나를 때린다. 노력의 이득 (이득).작업중인 코드에 따라 YMMV. – Terry
PB 10은 유니 코드를 도입했습니다. 어떤 방향으로 가든이 사실을 알고 있어야합니다. – Slapout