AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Look and Feel von Office 2007, welche Entwicklungsumgebung?

Look and Feel von Office 2007, welche Entwicklungsumgebung?

Ein Thema von Kedariodakon · begonnen am 30. Okt 2007 · letzter Beitrag vom 30. Okt 2007
Antwort Antwort
Seite 1 von 2  1 2   
Benutzerbild von Kedariodakon
Kedariodakon

Registriert seit: 10. Sep 2004
Ort: Mönchengladbach
833 Beiträge
 
Delphi 7 Enterprise
 
#1

Look and Feel von Office 2007, welche Entwicklungsumgebung?

  Alt 30. Okt 2007, 13:03
Hallo,
in Naher Zukunft sollen bei uns im Unternehmen alte in D7 entwickelte Programme neu gestaltet werden. Da es die Struktur nicht anders zulässt, müssen diese Programme für ein neues Design komplett neu geschrieben werden.
Die alten Oberflächen der Anwendungen sind alle grau, trist, überladen und ohne Benutzerführung, schlichtweg veraltet.
Zudem schreit das ganze System förmlich nach einem radikalen Schnitt! (Codemanagement, DB-Design…) (Warum, Wieso will ich jetzt hier nicht aufführen, wem es interessiert, der kann von der PM gebrauch machen)

Nach reichlicher Überlegung wollen wir nun weg von D7.
Auch scheut sich das neue dynamische Entwickler Team nicht den Umstieg auf eine andere Sprache…

So auf Anhieb fallen mir genau 2 Punkte ein, die für uns durchaus wichtig sind,
  • Mehrsprachigkeit
  • Datenbankanbindung (MSSQL 2005) mit möglichst vielen Features

Diese Sachen kann man natürlich auch mit D7 erreichen und sind auch erfolgreich umgesetzt.
Das was aber nun gemacht werden soll, ist eine komplett neues „Lock and Feel“ zu schaffen.

Geschaffen werden soll das „Look and Feel“ von Office 2007.
Nun meine Frage, ist das mit Delphi 2007 oder VS2005 (Visual Studio 2008) von Haus aus ohne zusätzliche Komponenten möglich (oder einer anderen Entwicklungsumgebung (Java ec..)? (.Net, win32?)
Ich habe keines der Entwicklungsumgebung und kann es daher nicht beurteilen.

Liebäugeln tun wir zurzeit sowieso schon mit einer Verwendung von C# im Bereich der Erweiterung des MSSQL2005 Servers, daher würde sich ein kompletter Umstieg auch anbieten, aber unser gutes altes Delphi haben wir auch lieb gewonnen...

Bye
Christian
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.604 Beiträge
 
#2

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 13:13
Erstmal schöne Grüße in meine alte Heimat (ich bin in Rheydt geboren)

1.) Egal ob Delphi /Win32 oder C#/.NET:
Es gibt keine "IDE" die von Haus aus Office 2007-Guis erzeugen lässt. Sowohl bei Delphi als auch in der .NET Welt braucht man dafür nicht ganz billige Zusatzkomponenten.

2.) Sakura hat ein solches UI für eine seiner neueren Anwendungen gebaut. Mit Komponenten von DevExpress - in Delphi 2007. Sieht Saugeil aus, und ist reines Delphi

Also stellt sich wirklich die Frage:
Wollt ihr wirklich zu 100% alles wegwerfen und von Null anfangen? Wollt Ihr Euch dabei auch noch gleichzeitig in eine neue Technologie (und ggf. Sprache) (.NET) einarbeiten, die definitiv eine gewisse Lernkurve mitbringt?

Wenn ja: Dann viel Spass mit C# (schaut Euch aber auch mal Chrome an).

Wenn ihr aber der Meinung seid, ihr könntet Teile Eures Codes weiterverwenden, auf der Win32-Plattform bleiben könnt - dann bleibt lieber beim bekannten Delphi, stattet Euch mit der aktuellen Version 2007 sowie passenden Komponenten aus (das Visual Studio ist auch nicht gerade billig), und legt dann in der bekannten VCL-Welt ggf. auf DBx4 los.
Sebastian Gingter
Phoenix - 不死鳥
Mein Blog: http://gingter.org
  Mit Zitat antworten Zitat
OregonGhost

Registriert seit: 8. Jun 2002
Ort: Lübeck
1.216 Beiträge
 
Delphi 3 Professional
 
#3

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 13:16
Aktuell gibt es als Extra für registrierte Visual C# 2005 Express-Benutzer eine Ribbon-Komponente kostenlos. Ich habe sie aber bisher nicht getestet, und ich weiß weder genau über die Lizenzbedingungen bescheid noch über die Nutzbarkeit der Komponente in den größeren Versionen. Aber das halt mal als Anhaltspunkt. Davon abgesehen kannst du dir aktuell einfach zum Testen die Beta von Visual Studio 2008 herunterladen, oder halt Visual C# 2005 Express als kostenlose Vollversion.

Für Mehrsprachigkeit gibt es in Visual Studio 2005 verschiedene Lösungen, bisher bin ich im Kleinen ganz gut damit gefahren, einfach das integrierte Ressourcen-Konzept mit Satelliten-Assemblys dafür zu verwenden, es funktioniert relativ gut und ist abgesehen davon, dass man keine "Namespaces" zur Verfügung hat, ohne für jeden eine eigene Assembly zu erstellen, ganz gut damit bedient, zumal die Ressourcen-Dateien nicht nur im integrierten Editor, sondern auch als einfaches XML-Format bearbeitet werden können. Der Zugriff gestaltet sich damit auch relativ einfach (es wird eine Klasse für den einfachen Zugriff generiert). Und, naja, dass Visual Studio 2005 eine gute Anbindung an den SQL-Server 2005 hat, sollte nicht überraschen.

Wie du schon sagtest, sollte jedoch nichts davon mit Delphi unmöglich sein.
Oregon Ghost
---
Wenn NULL besonders groß ist, ist es fast schon wie ein bisschen eins.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.169 Beiträge
 
Delphi 10.4 Sydney
 
#4

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 13:37
Wenn schon komplett neue Implementierung dann biete Datenbankneutral gestallten und nicht das Anti-Pattern "Vendor Lockin" einbauen.
Sollte z.B. mit (N)Hypernate relativ einfach zu realisieren sein.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
noidic

Registriert seit: 21. Nov 2005
Ort: Mönchengladbach
25 Beiträge
 
Delphi 7 Enterprise
 
#5

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 13:58
Ich würde die Wahl der Programmiersprache und -umgebung nicht primär davon abhängig machen, ob ich ein bestimmtes UI damit problemlos nachbauen kann. Wie teilweise schon gesagt bringt eine neue Sprache immer neue Aufwände mit sich, egal wie gut die Entwickler die Sprache schon können.
Wenn das Gesamtkunstwerk aus mehreren Einzelteilen besteht, die getrennt voneinder zu entwickeln sind, kann man auch überlegen, mehrere Möglichkeiten im ansatz zu evaluieren und sich dann für das passende entscheiden.

Zitat von Bernhard Geyer:
Wenn schon komplett neue Implementierung dann biete Datenbankneutral
gestallten und nicht das Anti-Pattern "Vendor Lockin" einbauen.
Das möchte ich so allgemein nicht unterschreiben. Warum soll man sich um die special features der einen Datenbank kastrieren, um auch andere unterstützen zu können? Ich denke das ist eine für jedes Projekt neu zu entscheidene Frage. Wir hatten auch mal den Anspruch, unsere Software DB-unabhängig zu bauen und haben dann irgendwann eingesehen, dass es mehr Sinn macht, Oracle als Vorraussetzung für den Betrieb unserer Software zu sehen, als nur im SQL-Standard zu arbeiten.
Für andere Projekte macht es durchaus sinn, soviele Datenbanksysteme wie möglich zu unterstützen.

Aber das gehört nur am Rande zum Thema.
The light at the end of the tunnel may be an oncoming dragon.
  Mit Zitat antworten Zitat
Benutzerbild von Kedariodakon
Kedariodakon

Registriert seit: 10. Sep 2004
Ort: Mönchengladbach
833 Beiträge
 
Delphi 7 Enterprise
 
#6

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 14:21
Zitat von Phoenix:
Egal ob Delphi /Win32 oder C#/.NET:
Es gibt keine "IDE" die von Haus aus Office 2007-Guis erzeugen lässt. Sowohl bei Delphi als auch in der .NET Welt braucht man dafür nicht ganz billige Zusatzkomponenten.
Nun ja, dass es Komponenten dafür gibt hab ich schon herausgefunden, auch die Preise dafür variieren ziemlich stark…
Nunja, aber ohne Entwicklungsumgebung kann man sich die auch schlecht testweise anschauen…

Zitat von Phoenix:
Wollt ihr wirklich zu 100% alles wegwerfen und von Null anfangen? Wollt Ihr Euch dabei auch noch gleichzeitig in eine neue Technologie (und ggf. Sprache) (.NET) einarbeiten, die definitiv eine gewisse Lernkurve mitbringt?
Im Grunde muss das System neu entwickelt werden, daher lassen sich nur kleine Teile der Sources weiterverwenden.

Zitat von Phoenix:
Wenn ihr aber der Meinung seid, ihr könntet Teile Eures Codes weiterverwenden, auf der Win32-Plattform bleiben könnt - dann bleibt lieber beim bekannten Delphi, stattet Euch mit der aktuellen Version 2007 sowie passenden Komponenten aus
Die Frage ist wie zukunftssicher ist diese Lösung? Pattform technisch ist dies weniger das Problem, da wir nicht nur die Software verkaufen sondern auch die Hardware und den Support stellen.

Zitat von Phoenix:
das Visual Studio ist auch nicht gerade billig
Auch nicht (viel) günstiger als neue Delphi Versionen denke ich.



Zitat von OregonGhost:
Aktuell gibt es als Extra für registrierte Visual C# 2005 Express-Benutzer eine Ribbon-Komponente kostenlos. Ich habe sie aber bisher nicht getestet, und ich weiß weder genau über die Lizenzbedingungen bescheid noch über die Nutzbarkeit der Komponente in den größeren Versionen. Aber das halt mal als Anhaltspunkt. Davon abgesehen kannst du dir aktuell einfach zum Testen die Beta von Visual Studio 2008 herunterladen, oder halt Visual C# 2005 Express als kostenlose Vollversion.
Danke für den Tip, ich werde mir das auf jeden fall mal anschauen.

Im Grunde werden wir eh. Alle Entwicklungsumgebungen näher zu Gemüte führen.


Zitat von Bernhard Geyer:
Wenn schon komplett neue Implementierung dann biete Datenbankneutral gestallten und nicht das Anti-Pattern "Vendor Lockin" einbauen.
Sollte z.B. mit (N)Hypernate relativ einfach zu realisieren sein.
Das macht ev. bei kleinen Projekten und Plattform unabhängigen Projekten, wo nur Software verkauft wird durchaus Sinn, aber eine Festlegung einer unterstützten Datenbank bei größeren Projekten (wie auch in diesem Fall) hat viele andere Vorteile die die Nachteile dieser Festlegungen mehr als wett machen…

Für uns kommt daher MSSQL in Frage, da damit die Entwickler hier die meiste Erfahrung haben, sich die derzeit verwendeten Statements teilweise weiterverwenden lassen.
Dazu ist zu sagen, dass bei uns eine VS2005 Version ins Haus kommen wird, für CLR Erweiterungen am MSSQL2005, keine Ahnung ob sich solche Erweiterungen auch mit Delphi .Net umsetzen lassen, ich denke mal nicht, bin mir aber nicht sicher. Auf jeden Fall werden solche Erweiterungen Einzug in unser System erhalten, da dies wirklich ein mächtiges Werkzeug darstellt.

Wer nicht weiß, was das ist, dem kann ich den Comunity Cast (CLR) empfehlen, gibt einen kleinen Einblick in die Möglichkeiten.

Zitat von noidic:
Ich würde die Wahl der Programmiersprache und -umgebung nicht primär davon abhängig machen, ob ich ein bestimmtes UI damit problemlos nachbauen kann. Wie teilweise schon gesagt bringt eine neue Sprache immer neue Aufwände mit sich, egal wie gut die Entwickler die Sprache schon können.
Damit hast du Recht, wir werden auch nicht deswegen nun eine Entwicklungsumgebung aussuchen, nur ist es schön zu erfahren ob so was schon von Haus aus mitgeliefert wird.


Angeschaut werden sich auf jeden Fall alle Umgebungen, solch eine Entscheidung kann man nicht über Nacht fällen
Christian
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.169 Beiträge
 
Delphi 10.4 Sydney
 
#7

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 14:27
Zitat von Kedariodakon:
Das macht ev. bei kleinen Projekten und Plattform unabhängigen Projekten, wo nur Software verkauft wird durchaus Sinn, aber eine Festlegung einer unterstützten Datenbank bei größeren Projekten (wie auch in diesem Fall) hat viele andere Vorteile die die Nachteile dieser Festlegungen mehr als wett machen…
Das würde ich nicht an der Projektgröße festlegen. Wir haben ein Projekt mit über 1 Mio. Quellcodezeilen und haben einen DB-Neutralen Ansatz. Nur wenn es eine Inhouse-Lösung ist oder Kundenspezifisches Projekt würde ich die Kapslung aufweichen.

Zitat von Kedariodakon:
... für CLR Erweiterungen am MSSQL2005, keine Ahnung ob sich solche Erweiterungen auch mit Delphi .Net umsetzen lassen, ich denke mal nicht, bin mir aber nicht sicher. Auf jeden Fall werden solche Erweiterungen Einzug in unser System erhalten, da dies wirklich ein mächtiges Werkzeug darstellt.
Hat nicht jemand auf der EKON 11 angemerkt das dies u.U. ein riesiges Performancegrab darstellen kann.
MS SQL-Server 2005 ist nunmal AFAIK nicht eine 100% Managed Anwendung.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
generic

Registriert seit: 24. Mär 2004
Ort: bei Hannover
2.415 Beiträge
 
Delphi XE5 Professional
 
#8

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 14:32
Zitat von Bernhard Geyer:
Sollte z.B. mit (N)Hypernate relativ einfach zu realisieren sein.
Ich denke du meinst Hibernate (a persistence framework).

http://www.hibernate.org/
Coding BOTT - Video Tutorials rund um das Programmieren - https://www.youtube.com/@codingbott
  Mit Zitat antworten Zitat
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: München
11.412 Beiträge
 
Delphi 11 Alexandria
 
#9

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 14:35
Zitat von Bernhard Geyer:
MS SQL-Server 2005 ist nunmal AFAIK nicht eine 100% Managed Anwendung.
Der Server selbst ist [berhaupt nicht managed, er unterstützt lediglich die Einbindung von managed Code, und ja, das ist sehr oft ein Performancegrab und lohnt sich nur selten.

Warum? Einfach: alle übermittelten Werte müssen in .NET-Objekte umgewandelt werden, wenn die Methoden aufgerufen werden und alle zurück gelieferten Objekte müssen nach dem Aufruf zurück gewandelt werden. Es ist selten, dass dieser Overhead durch den Vorteil managed Code zu verwenden wieder ausgeglichen wird.

......
Daniel W.
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
Benutzerbild von Kedariodakon
Kedariodakon

Registriert seit: 10. Sep 2004
Ort: Mönchengladbach
833 Beiträge
 
Delphi 7 Enterprise
 
#10

Re: Look and Feel von Office 2007, welche Entwicklungsumgebu

  Alt 30. Okt 2007, 14:48
Zitat von Bernhard Geyer:
Das würde ich nicht an der Projektgröße festlegen. Wir haben ein Projekt mit über 1 Mio. Quellcodezeilen und haben einen DB-Neutralen Ansatz.
Ok, falsch ausgedrückt, vielleicht ist Projekt-/Systemumfang die passendere Wahl.
Jedefalls hat so eine Festlegung nicht nur Nachteile.

Zitat von Bernhard Geyer:
Hat nicht jemand auf der EKON 11 angemerkt das dies u.U. ein riesiges Performancegrab darstellen kann.
KANN, das ist der Punkt.
Es gibt Sachen, die lassen sich über CLRs sicher schön und sauberer lösen, als mit klassischen Erweiterungen per dll.
Das es nicht das Allheilmittel ist, dem bin ich mir bewust.

Zudem steht manchmal auch Performance nicht an erster Stelle.
Christian
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:11 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz