PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Visual Basic 6


Brillenschlange92
2005-12-30, 19:50:13
[gelöscht]

Juerg
2005-12-30, 21:48:55
Es gibt nichts was Du nicht auch in VB6 machen könntest... Inline-Assembler, >50fps Software Blitter, Multi-Tier Anwendungen, (ok ausser Interface-Inheritance geht keine Vererbung für die Hardcore-Idealisten-OOP :rolleyes:)

Aber: Wieso verwendest Du nicht VB.NET oder noch besser C# :confused:

edit: Ahh ja... es gibt Sie: VB Programmierer :|

Coda
2005-12-31, 00:24:03
Es gibt nichts was Du nicht auch in VB6 machen könntest... Doch. Schönen Code schreiben *scnr*

Controller Khan
2005-12-31, 00:58:38
Visual Basic als Konzept ist gut, nur an der Umsetzung hapert es enorm, dazu kommen eine Menge Bugs und sehr unlogisches Verhalten.

Für Anfänger ist es vielleicht o.k, man lernt aber nicht wirklich gut programmieren.

Der Ressourcen-Editor ist ein Witz und total verbugt. Die Objektorientierung ist unvollständig, Threading ist nicht vorhanden.
Für alles braucht ein OCX, und dann funzt es immer noch nicht z.B. Winsock.
Man braucht ein OLE/DCOM Update selbst unter Win98FE, damit die Exe überhaupt startet, außer man verzichtet auf OLE Automation.

Ich habe es aufgegeben in VB irgendetwas zu schreiben und bleibe lieber bei Delphi.

Meine Erfahrungen beziehen sich auf VB 6 SP6.

Spearhead
2005-12-31, 01:00:41
Hm, also in meinem Praktikum muß ich auch in VB 6 proggen... also ja, solche Coder gibt es durchaus noch ;)

@Coda: Ansichtssache was man als schönen Code empfindet ;)

Brillenschlange92
2006-01-02, 10:29:54
[gelöscht]

Crushinator
2006-01-02, 11:20:06
Doch. Schönen Code schreiben *scnr*
Es gibt noch mehr, was man mit VB6 schlicht nicht tun kann.


Mit Threads arbeiten
Richtige Vererbung
Ohne Nachkommafehler mit Doubles rechnen

X-D

Hucke
2006-01-02, 11:51:32
Es gibt noch mehr, was man mit VB6 schlicht nicht tun kann.


Mit Threads arbeiten
Richtige Vererbung
Ohne Nachkommafehler mit Doubles rechnen

X-D

Threads gehen doch mittlerweile in VB.net. Und die Nachkommafehler sind einfach ein Problem der computerinternen Zahlendarstellung. Da ist VB aber bei weitem nicht alleine.

grakaman
2006-01-02, 12:00:15
Mit Threads arbeiten



Na klar kannst du Multithreaded Anwendungen erstellen.



Ohne Nachkommafehler mit Doubles rechnen



IEEE Format verstanden?

zeckensack
2006-01-02, 12:46:45
Funktionszeiger.
Und das Korollar: Code aus DLLs nutzen
Mit VB6 kann man Komponenten zusammenstöpseln, die andere geschrieben haben, und für die andere Leute in anderen Sprachen Schnittstellen für VB6 erzeugt haben.
Programmieren ist IMO was anderes.

Juerg
2006-01-02, 13:09:08
Mit Threads arbeitenJohn Robbins
Ingenious Ways to Implement Multiple Threads in Visual Basic 5.0, Part I
http://www.microsoft.com/msj/0897/multithreading.aspx

Richtige VererbungInterface Inheritance... Zumal tiefe Vererbungsstrukturen eher zu zusätzlichen Problemen führen, denn Lösungen anbieten.

Inheritance
http://www.marin.clara.net/oo/inheritance.htm#Inheritance%20between%20Interfaces


Ohne Nachkommafehler mit Doubles rechnen- Führt Fliesskomma-Präzisionsberechnungen aus
- Eine (1) bis zu 200 signifikante Stellen
- Über 90 arithmetische, trigonometrische, logarithmische, exponentielle und Matrizen- Funktionen
- Referenz-Dokumentation
- Kompatibel mit Microsoft Visual Basic 6.0
- Kompatibel mit Microsoft Windows 2000/XP
- Free Open Software


Interessiert..? :wink:

Juerg
2006-01-02, 13:16:02
Mit VB6 kann man Komponenten zusammenstöpseln, die andere geschrieben haben, und für die andere Leute in anderen Sprachen Schnittstellen für VB6 erzeugt haben.Genau! Warum das Rad jedesmal neu erfinden?
Programmieren ist IMO was anderes. :biggrin:

Brillenschlange92
2006-01-02, 13:42:01
[gelöscht]

Juerg
2006-01-02, 13:51:14
cool :confused:

Crushinator
2006-01-02, 13:57:19
John Robbins
Ingenious Ways to Implement Multiple Threads in Visual Basic 5.0, Part I
http://www.microsoft.com/msj/0897/multithreading.aspx

Das kenne ich bereits, das interessante warum man damit trotzdem nicht arbeiten kann ist:


Before I can show you a simple Visual Basic-based program that does multithreading, there are three things that you must know about developing these types of applications. First, you cannot use the Visual Basic IDE to run or debug your application. If you try to run the programs I wrote for this article inside the IDE, it will crash.

Interface Inheritance... Zumal tiefe Vererbungsstrukturen eher zu zusätzlichen Problemen führen, denn Lösungen anbieten.

Inheritance
http://www.marin.clara.net/oo/inheritance.htm#Inheritance%20between%20Interfaces


Oh, mir war entgangen, daß man auch noch Polymorphes vererben kann. ;)

(...) Interessiert..? :wink:
Nein, danke. So interessiert bin ich an Basic auch nun wieder nicht um mich ernsthaften Lösungsansätzen zu widmen. Es ging mir eigentlich nur darum zu sagen, daß VB6 doch "etwas" eingeschränkt ist. :)

Juerg
2006-01-02, 14:05:19
Threading: Arbeiten damit ist äussert schwierig, ja. Es ging aber um die Existenz nicht um die Implementation.

Du hast ja recht. VB6 ist "etwas" eingeschränkt und niemanden zu empfehlen.
(Support ist vom Hersteller sowieso eingestellt worden, didaktisch ist VB6 eine mittlere Katastrophe... ;D)

Brillenschlange92
2006-01-02, 17:47:03
[gelöscht]

Trap
2006-01-02, 17:59:36
http://msdn.microsoft.com/vstudio/express/vb/default.aspx gibt es. Ob das jetzt gut ist will ich nicht beurteilen ;)

FlashBFE
2006-01-02, 18:16:18
Also wenn du noch Anfänger bist, dann würde es sich wirklich lohnen gleich mit VB.NET anzufangen und VB6 zu vergessen.

Am Besten bei Microsoft das Visual Basic 2005 Express runterladen und schon kanns losgehen.

Wenn du jedoch wirklich noch prozedural programmieren willst, ist gegen VB6 oder VBA nichts einzuwenden. Nur je länger du das machst, desto schwerer fällt es dir dann, auf wirklich objektorientierte Programmiersprachen wie VB.NET umzusteigen.

Crushinator
2006-01-03, 11:35:05
Redet ihm bloß nix mit prozedural ein. Also, liebe Brillenschlange, versuch's bitte lieber mit VB 2005 Express und lasse VB6 einfach liegen. :)

Brillenschlange92
2006-01-03, 12:59:42
[gelöscht]

Brillenschlange92
2006-01-07, 16:07:18
[gelöscht]

Brillenschlange92
2006-01-08, 14:47:11
[gelöscht]

SynchroM
2006-01-08, 15:30:28
Hallo Brillenschlange.
Also ich selbst habe lange mit VB6 gearbeitet und möchte dir folgendes sagen:
VB6 ist schlicht verhalltet. Software auf moderne OS's zu betreiben ist genauso unbefriedigend wie damit große Projekte zu machen.
Aus diesem Grund empfehlen viele VB.net. VB.net erzeugt Code für das .net Framework, es kann also exakt das gleiche wie Delphi.net, C#, Java.net, C++.net und wasweißichnochalles. Deshalb sieht der Code auch so ähnlich aus...
AAAAAber: das .net FW wird von C# am besten abgebildet. Diese Sprache wurde speziell dafür entworfen. (genau so wie VB6 für das VB-Framework entworfen wurde) Aus diesem Grund empfehle ich dir, als Anfänger auf jeden Fall mit C# anzufangen. das Kann alles, und ist komplett Objektorientiert aufgebaut.
Die anderen .net Sprachen können zwar das gleiche, sind aber eher für Leute die Sprache XY gelernt haben und sich nicht mehr umlernen wollen. Gegenüber c# ist jede Sprache XY.net also eher Flickwerk.

SynchroM
2006-01-08, 15:43:56
Funktionszeiger.
Funktionszeiger sind die Softwareimplementierung von Callbacks, sind in einem Anwenderprogramm aber reine Fehlerquellen. Aus diesem Grund verzichen moderne Sprachen komplett auf die Zeigerarithmetik. Wenn eine sub "btnXY_Click" heißt, dann wird genauso ein Funktionszeiger im VB-FW gespeichert, aber halt sauber gekappselt, dass der Programmierer kein Scheiß damit anstellen kann.

Code aus DLLs nutzen
häää?


Programmieren ist IMO was anderes.
so, 1337 hat gesprochen, nehme ich an.

Brillenschlange92
2006-01-09, 14:42:42
[gelöscht]

FlashBFE
2006-01-09, 16:16:06
AAAAAber: das .net FW wird von C# am besten abgebildet. Diese Sprache wurde speziell dafür entworfen. (genau so wie VB6 für das VB-Framework entworfen wurde) Aus diesem Grund empfehle ich dir, als Anfänger auf jeden Fall mit C# anzufangen. das Kann alles, und ist komplett Objektorientiert aufgebaut.
Die anderen .net Sprachen können zwar das gleiche, sind aber eher für Leute die Sprache XY gelernt haben und sich nicht mehr umlernen wollen. Gegenüber c# ist jede Sprache XY.net also eher Flickwerk.

Woher hast du denn die Behauptung?
Es ist doch egal, mit welcher Syntax man für das .net Framework programmiert, die Programme sind immer 1:1 in die andere Syntax umwandelbar. Eigentlich müsste die "Programmiersprache" .NET heißen und VB.net, C#, J# ... sind nurnoch Benutzerschnittstellen zum Code eintippen. Insofern ist es egal, was er davon benutzt.

Gast
2006-01-09, 17:18:24
Nein es stimmt schon dass es auf C# ausgelegt ist!

FlashBFE
2006-01-09, 18:10:07
Hehe da könnte ich ja genauso sagen, dass ein Auto für die Straße ausgelegt ist. Das hätte den selben inhaltlichen Wert. Sag doch mal explizit ein Beispiel, was nur mit C# geht und mit VB.net oder J# oder sonstwas nicht! Es wird dir keins einfallen.

Der_Donnervogel
2006-01-09, 20:19:15
ok ...
ich hab ne vb.net testversion (60tage) muss ich noch installieren ...

zwischenfrage:
wie kann ich in vb6 sound ohne ole integrieren?
Also recht einfach wär es schon den Windows Media Player als Komponente zu integrieren, aber man kann das sicher auch anders machen, zB über das Windows-API:


Public Declare Function PlaySound Lib "winmm.dll" Alias "PlaySoundA" (ByVal lpszName As String, ByVal hModule As Long, ByVal dwFlags As Long) As Long
Public Const SND_FILENAME = &H20000 ' name is a file name


und irgendwo dann im Code was in der Art:


PlaySound "C:\WINDOWS\Media\tada.wav", 0, SND_FILENAME

Coda
2006-01-09, 21:10:11
DirectSound kann man auch verwenden, aber das ist wohl mit Kanonen auf Spatzen geschossen.

Brillenschlange92
2006-01-10, 14:48:00
[gelöscht]

Brillenschlange92
2006-01-10, 17:26:17
[gelöscht]

FlashBFE
2006-01-10, 18:19:40
mist vb6 bringt fehlermeldungen wenn ich complieren will
wo soll ich
Public Declare Function PlaySound Lib "winmm.dll" Alias "PlaySoundA" (ByVal lpszName As String, ByVal hModule As Long, ByVal dwFlags As Long) As Long
Public Const SND_FILENAME = &H20000 ' name is a file namehinschreiben?

Innerhalb des Deklarationsteils eines Moduls oder einer Klasse.

zeckensack
2006-01-10, 21:17:05
Funktionszeiger sind die Softwareimplementierung von Callbacks, sind in einem Anwenderprogramm aber reine Fehlerquellen.Funktionszeiger sind nicht nur für Callbacks verwendbar. Ich weiß nicht wie du auf den Ast kommst.
Funktionszeiger sind eben Funktionszeiger, und erlauben bestimmte Formen von Polymorphie ... und ja, Funktionszeiger per se sind sogar typsicher.
Aus diesem Grund verzichen moderne Sprachen komplett auf die Zeigerarithmetik.Funktionszeiger haben mit Zeigerarithmetik soviel zu tun wie Code-Kommentare mit Division.häää?Was ich schrieb: Code aus DLLs nutzen. Nimm dir eine beliebige DLL, versuche diese zu laden und eine beliebige Funktion zu importieren. Das wird dir exakt dann gelingen, wenn irgendjemand für VB ein Import-Modul geschrieben hat, und zwar in einer anderen Sprache als VB, weil man das in VB nicht kann!

Ungläubig? Gut. Lade dir folgendes Archiv herunter:
http://zeckensack.de/mandel/brot.zip
Darin ist eine DLL, die heißt brot_core.dll. Lade die doch bitte in einem VB-Programm, und importiere die Funktion bc_describe_generator. Die nutzt die __cdecl-calling convention, nimmt ein Integer-Argument, und gibt einen C-String (zeiger auf char) zurück.

Recht viel Vergnügen damit. Ich bin gespannt.

Juerg
2006-01-10, 22:32:24
Recht viel Vergnügen damit. Ich bin gespannt.Strategie ist die Folgende: C-calling convention mittels einer simplen 1:1 wrapper DLL nach Pascal-calling convention und exportieren mit DEF file. Diese DLL erlaubt dann Zugriff von VB auf brot_core über Umweg von Wrapper-DLL. :wink:

Ungefähr so: (Habs nicht getestet, kein error control usw...)

Bitte keine abfälligen Kommentare über Schönheit oder Performance einer solchen Lösung. =)

C Part
-------
// DEF File
LIBRARY wrap_brot_core

CODE PRELOAD MOVEABLE DISCARDABLE
DATA PRELOAD MOVEABLE

EXPORTS
wrap_bc_describe_generator @1



// C DLL

BSTR __stdcall wrap_bc_describe_generator(int x)
{
char * theLIB;
char * theFunction;
LPSTR lpTheString;

theLIB = "brot_core.dll";
theFunction = "bc_describe_generator"

HINSTANCE hLib=LoadLibrary(theLIB);

myfct = GetProcAddress((HMODULE)hLib, theFunction);
lpTheString = myfct(x);

FreeLibrary((HMODULE)hLib);
return((BSTR)lpTheString));
}VB Part
--------Option Explicit

Private Declare Function wrap_bc_describe_generator _
Lib "c:\brot\wrap_brot_core.dll" _
(ByVal uInt As Long) As String


Private Sub Command1_Click()
Text1.Text = wrap_bc_describe_generator(5)
End Sub

Juerg
2006-01-10, 22:35:08
Was ich schrieb: Code aus DLLs nutzen. Nimm dir eine beliebige DLL, versuche diese zu laden und eine beliebige Funktion zu importieren. Das wird dir exakt dann gelingen, wenn irgendjemand für VB ein Import-Modul geschrieben hat, und zwar in einer anderen Sprache als VB, weil man das in VB nicht kann!Das ist exakt und Du hast damit natürlich recht.

Juerg
2006-01-10, 22:37:38
Innerhalb des Deklarationsteils eines Moduls oder einer Klasse.Public Declare geht nur in Modul, Private Declare geht auch in Klasse.

Juerg
2006-01-10, 22:39:53
jo danke
kann ich auch nur PlaySound "xy.wav", 0, SND_FILENAME
eingeben?
oder muss der Pfad auch mit?Jo, Latürnich muss Pfad auch mit, es sei denn, dass *wav gerade zufälligerweise in App.Path ist.

Der_Donnervogel
2006-01-10, 22:41:33
jo danke
kann ich auch nur PlaySound "xy.wav", 0, SND_FILENAME
eingeben?
oder muss der Pfad auch mit?
Das kommt drauf an wo die Datei liegt. Wenns irgendwo im Suchpfad liegt, dann findet VB es auch ohne Pfadangabe. Falls es irgendwo im Programmordner liegt, kann man das auch mit App.Path abkürzen, sonst muß man halt den ganzen Pfad bemühen.

zB.


PlaySound App.Path & "\Sound\tada.wav", 0, SND_FILENAME

Juerg
2006-01-10, 22:43:23
Also ich selbst habe lange mit VB6 gearbeitet [...]Wie lange ist lange?

Juerg
2006-01-10, 22:45:37
irgendwo im SuchpfadJa, hast recht.

Brillenschlange92
2006-01-12, 14:24:19
[gelöscht]

Der_Donnervogel
2006-01-12, 21:54:43
ok ...
ich muss also ne dll runterladen, einbinden und dann ...läufts?
aha
Ich vermute mal mit runterladen ist das

Ungläubig? Gut. Lade dir folgendes Archiv herunter:
http://zeckensack.de/mandel/brot.zip
Darin ist eine DLL, die heißt brot_core.dll.

gemeint. Das hat nichts mit Sound zu tun, da ist es um etwas vollkommen anderes gegangen (die brote_core.dll gehört zu einem Mandelbrotprogramm).

Wie gesagt, wenn keine Komponente verwedet werden soll, dann die Windows-API Funktionen nehmen. DirectX ist auf jeden Fall zu kompliziert, wenn schon das einbinden der Windows-API-Funktionen nicht auf Anhieb geklappt hat.

Brillenschlange92
2006-01-13, 14:22:28
[gelöscht]

Brillenschlange92
2006-01-14, 12:43:29
[gelöscht]

Der_Donnervogel
2006-01-14, 23:13:48
wie geht das mit demj sound jetzt?

Die beiden Deklarationen


Public Declare Function PlaySound Lib "winmm.dll" Alias "PlaySoundA" (ByVal lpszName As String, ByVal hModule As Long, ByVal dwFlags As Long) As Long
Public Const SND_FILENAME = &H20000 ' name is a file name

kann man in ein Modul (also eine .bas Datei) geben.

Alternativ, kann man sie auch in ein Form oder eine Klasse geben, dann muß aber wenigstens die Konstante auf Private geändert werden. Kleines Beispiel (den Code einfach in ein neues Form kopieren):

Option Explicit
' Soundfunktion aus Windows-Dll
Private Declare Function PlaySound Lib "winmm.dll" Alias "PlaySoundA" (ByVal lpszName As String, ByVal hModule As Long, ByVal dwFlags As Long) As Long
' Konstante deklarieren
Private Const SND_FILENAME = &H20000 ' name is a file name
' Den Command Button deklarieren
Private WithEvents ButPlaySound As CommandButton

Private Sub ButPlaySound_Click()
Call PlaySound("tada.wav", 0, SND_FILENAME)
End Sub

Private Sub Form_Load()
' den Command Button dynamisch erzeugen
Set ButPlaySound = Controls.Add("VB.CommandButton", "PlaySoundButton")
ButPlaySound.Caption = "PlaySound"
ButPlaySound.Visible = True
End Sub

Brillenschlange92
2006-01-15, 11:55:42
[gelöscht]

Xmas
2006-01-15, 12:57:21
Woher hast du denn die Behauptung?
Es ist doch egal, mit welcher Syntax man für das .net Framework programmiert, die Programme sind immer 1:1 in die andere Syntax umwandelbar. Eigentlich müsste die "Programmiersprache" .NET heißen und VB.net, C#, J# ... sind nurnoch Benutzerschnittstellen zum Code eintippen. Insofern ist es egal, was er davon benutzt.
Microsoft hat natürlich einiges getan, damit die eigenen CLR-Sprachen (VB.net, C#, J#, pures Managed C++) möglichst alle CLR-Möglichkeiten nutzen können. Das heißt aber noch lange nicht dass die Programme 1:1 ineinander umwandelbar wären, und erst recht gilt das nicht für die Dutzende anderer Sprachen, die für die CLR kompilieren.

Hier mal ein Vergleich von C# und VB.net (http://www.codeproject.com/dotnet/vbnet_c__difference.asp). Da sind doch noch ein paar "n/a" aufgeführt. Manche sind syntactic sugar, andere wie unsafe code, Iteratoren, volatile bei C# oder der nichtvirtuelle Aufruf einer virtuellen Methode bei VB.net sind es nicht.

ScottManDeath
2006-01-15, 13:19:13
Richtige Männer denken den Gedanken "Visual Basic.NET" zu Ende und programmieren in COBOL.NET

Für die versteckten Romanautoren unter uns =)

HellHorse
2006-01-15, 17:27:02
Für die versteckten Romanautoren unter uns =)
Mit COBOL programmieren kann man _richtig_ Geld machen. Und hat einen super sicheren Job für die nächsten 30 Jahre oder so. Ich glaube ich poste im nächsten `Welche Sprache für mich'-Thread COBOL.

Ok, man muss Masochist sein, aber irgendwie hat doch alles einen Haken.

Coda
2006-01-15, 18:13:05
Naja COBOL zu lernen ist aber auch nicht so das große Problem nehme ich an.

Marscel
2006-01-15, 18:36:47
Was ist das besondere an Cobol, oder war das Ironie?

ScottManDeath
2006-01-15, 23:27:06
Was ist das besondere an Cobol, oder war das Ironie?

COBOL, der Klassiker aus den 60ern. Viele Versicherungen und Banken nutzen noch ihre COBOL Systeme und holen die Renter aus Hawaii um die Systeme weiter zu pflegen. ;)

COBOL ist wohl die einzige Sprache, deren Code man vorlesen kann ;)

Brillenschlange92
2006-01-16, 14:35:45
[gelöscht]

(del)
2006-01-16, 15:24:10
Fontdatei in der Distribution mitliefern, per Programmfunktion ins Fontverzeichnis kopieren. Fertig.

Wat soll das denn werden? Sollen wir dir hier auch noch das komplette Programm schreiben? Lies dir mal bitte Grundlagen zu VB6 durch.

HellHorse
2006-01-16, 16:47:47
Naja COBOL zu lernen ist aber auch nicht so das große Problem nehme ich an.
Ne das nicht, ein 30 Jahre altes legacy System zu maintainen schon. X-D

Coda
2006-01-16, 17:44:13
Wohl wahr, wohl wahr :)

Brillenschlange92
2006-01-16, 18:07:45
[gelöscht]

zeckensack
2006-01-16, 18:09:56
danke
wisst ihr auch wie mann .ocx und schrift-dateien einbindet?Fonts:
a)Der dritte Treffer der Google-Suche "bundling fonts with software site:microsoft.com" liefert alle Informationen die du brauchst.
Der hier (http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part3/proch16.mspx).
To install a font by dragging or pasting a font file

1.

Find the font file you want to install (on a floppy disk, network share, or vendor's Web site).

2.

Drag or paste the font into the \winnt\fonts directory, for example c:\winnt\fonts.Dh eine Truetype-Schriftart kann "installiert" werden indem sie einfach in %windir%\fonts kopiert wird.
Bitte unbedingt %windir% korrekt auflösen, und nicht hardcoded "C:\Windows\fonts\" annehmen!

Allerdings kommt dann noch das:Caution Never bundle fonts with applications.:|
Leider wird nicht gesagt warum.

b)Da dein Programm nun aus mehreren Dateien besteht, die auf dem Zielrechner auch noch in mehrere unterschiedliche Verzeichnisse gehören, wirst du einen Installer brauchen. Ich empfehle immer wieder gerne NSIS (http://nsis.sourceforge.net/Main_Page). Alles andere (auch und gerade kommerzielle, "professionelle" Installer) ist IMO ranziger, schäbiger Scheißdreck dagegen.

Brillenschlange92
2006-01-16, 18:32:50
[gelöscht]

zeckensack
2006-01-16, 18:58:42
äh ... soll ich jetzt "c.//%fonts%" schreiben oder wie?Nein. Gleich mehr dazu. Erstmal raffe ich nämlich nicht wie beim Teutates du jetzt auf "c.//" kommst. Was soll das denn sein? Ein Laufwerksbuchstabe ist sowieso falsch, der Punkt auch, und zwei Slashes nicht am Anfang eines Pfades (dann wär's eine Netzwerkidentifikation) erst recht. Du sollst die Variable %windir% auflösen, um das Windows-Verzeichnis zu lokalisieren, weil nämlich der User bei der Installation dafür einen beliebigen Namen und ein beliebiges Laufwerk auswählen kann, und es Scheiß-Stil ist, fix von "C:\Windows\" auszugehen.

%fonts% sollst du nicht auflösen, kannst du auch nicht, weil diese Variable nicht existiert. Der Name des Font-Verzeichnisses ist nämlich konstant ... "fonts" ... und es liegt immer innerhalb des Windows-Verzeichnisses.

So.

Es gibt ungefähr zwei Möglichkeiten %windir% aufzulösen:
1)ExpandEnvironmentStrings (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/expandenvironmentstrings.asp)
Müsste in etwa so aussehen:ExpandEnvironmentStrings "%windir%\fonts\deinfont.ttf", schau_unten, schau_unten;Ich bin in der VB6-Syntax nicht so recht bewandert, von daher fehlen mir zwei Parameter.
Der zweite soll ein Zeiger auf einen leeren String sein, in dem das fertige Ergebnis abgelegt wird (auf Standard-Windows 2000-Installation zB "C:\WINNT\fonts\deinfont.ttf", bei XP "C:\Windows\fonts\deinfont.ttf" usw). Der dritte Parameter ist die Länge dieses leeren Strings.

Wichtig ist eben dass der String schon vor Aufruf der Funktion eine bekannte Länge hat, die für die Expansion auch ausreicht. Ein dynamisch sich-selbst-verlängernder String wird nicht funktionieren.

2)Du lässt das innerhalb deines Programms schön bleiben und sorgst stattdessen dafür dass der Installer das kann. "Gefunden" wird der Font zur Laufzeit sowieso, wenn er denn im korrekten Verzeichnis angekommen ist. Du lädst ihn dann halt als "deinfont.ttf" komplett ohne Pfadangabe.

Als NSIS-Skript (wo du dich auch noch einlesen müsstest, wenn du das nutzen willst) sieht das zB so aus:;put the fonts in the system font directory
SetOutPath "$WINDIR\fonts"
File "wo_er_auf_deinem_rechner_ist\deinfont.ttf"

SetOutPath "$INSTDIR"
File "blafasel.exe"
File "irgendwas_buntes.bmp"
...

Juerg
2006-01-16, 20:18:40
The hard way geht so:Private Declare Function ExpandEnvironmentStrings _
Lib "kernel32" Alias "ExpandEnvironmentStringsA" _
(ByVal lpSrc As String, _
ByVal lpDst As String, _
ByVal nSize As Long) As Long

Private Function ExpandEnvStr(sData As String) As String
Dim c As Long
Dim s As String
' Get the length
c = ExpandEnvironmentStrings(sData, s, c)
' Expand the string
s = String(c - 1, 0)
c = ExpandEnvironmentStrings(sData, s, c)
ExpandEnvStr = s
End Function

oder eben gleich VB internes verwenden:getit = Environ("windir")
@zeckensack - Hast Du gesehen wie man brot_core mit VB ansprechen kann? :wink:

zeckensack
2006-01-16, 20:43:46
@zeckensack - Hast Du gesehen wie man brot_core mit VB ansprechen kann? :wink:Ja, ich hab's gesehen, und es hat meine Erwartungen auch mehr oder weniger erfüllt. GetProcAddress direkt in VB6 zu nutzen ist eben nicht drin, wegen der fehlenden Funktionszeiger. Dafür brauchtest du den Wrapper allerdings nicht, wenn ich das richtig sehe, sondern weil der VB6-Linker nur __stdcall-Funktionen direkt importieren kann ... korrekt?

Dann hatte ich ja eigentlich Unrecht, allerdings ein glückliches Händchen mit meinem Beispiel :usweet:

So richtig spannend wäre es wohl mit DLLs die keine sinnvollen DEFs und/oder Importmodule haben, und wo man auf GetProcAddress angewiesen ist. Wie zB OpenGL-Treiber auf Win32.
Eine Implementation exportiert zB die Funktionen A,B,C und D, und eine andere exportiert A,B,E und F, aber nicht C und D =)

In C oder C++ ist das kein Problem. Funktionszeiger, GetProcAddress und fertig ist der Lack.

Gast
2006-01-16, 22:45:02
Dafür brauchtest du den Wrapper allerdings nicht, wenn ich das richtig sehe, sondern weil der VB6-Linker nur __stdcall-Funktionen direkt importieren kann ... korrekt?


Richtig, den Wrapper bräuchtest du auch nicht.

Brillenschlange92
2006-01-17, 15:45:05
[gelöscht]

Juerg
2006-01-17, 18:36:41
Ja, ich hab's gesehen, und es hat meine Erwartungen auch mehr oder weniger erfüllt. GetProcAddress direkt in VB6 zu nutzen ist eben nicht drin, wegen der fehlenden Funktionszeiger. Dafür brauchtest du den Wrapper allerdings nicht, wenn ich das richtig sehe, sondern weil der VB6-Linker nur __stdcall-Funktionen direkt importieren kann ... korrekt?Korrekt.So richtig spannend wäre es wohl mit DLLs die keine sinnvollen DEFs und/oder Importmodule haben, und wo man auf GetProcAddress angewiesen ist. Wie zB OpenGL-Treiber auf Win32.
Eine Implementation exportiert zB die Funktionen A,B,C und D, und eine andere exportiert A,B,E und F, aber nicht C und D =)?Ja dann wirds richtig spannend... (Mann muss mit ein wenig trickery VB "inline-assembly" beibringen) ;)


Copyright (c) Matthew Curland für Visual Basic Programmers Journal Issue Feb. 2000

http://www.ftponline.com/archives/premier/mgznarch/vbpj/2000/02feb00/mc0200/mc0200f1.gif

;Remove the return address from
;the stack and store it in a
;temporary register for later
;retrieval
pop ecx

;Remove the this pointer from
;the stack
pop eax

;push the return address back
;on the stack so that the function
;pointer knows where to return to
push ecx

;turn control over to the function
;pointer stored at offset 4 in the
;this pointer
jmp DWORD PTR [eax + 4]Der Assembly Code für diese vier Instruktionen ist nur sechs Bytes: 59 58 51 FF 60 04. Man muss sie padden mit zwei Int3 Instruktionen (CC CC) um daraus 8 Bytes zu erhalten, die dann genau in eine VB Currency Variable passen. Die Adresse der Currency Variable die

"magische Nummer": 368956918007638.6215@

enthält ist ein Funktions-Zeiger (function pointer) zu der Delegator-Funktion. Diese Funktion entfernt den entfernt den Pointer vom Stack und springt zu jeder Funktion, egal der übergebenen Parameter. Dies bewirkt, dass der gleiche Assembly-Code benutzt werden kann, um jeden Funktionsaufruf zu delegieren. Wir benötigen nun eine VTable die einen Pointer enthält zum dem Stream der Bytes, was ja aktuell eine Funktion ist. :biggrin:

Coda
2006-01-17, 18:39:36
Meine Augen *wuaaah*

Juerg
2006-01-17, 18:57:53
Meine Augen *wuaaah*hast Du was an Deinen Blinker :confused: :eek: ... kräze oder so...? :biggrin:

Coda
2006-01-17, 19:05:54
Jetzt schon X-D

Juerg
2006-01-17, 19:12:54
Warum?

Coda
2006-01-17, 19:47:39
Also das ist mal ein übler Hack der bösesten Sorte - deshalb.

Juerg
2006-01-17, 20:31:00
Also das ist mal ein übler Hack der bösesten Sorte - deshalb. :ass: :whistle: :whisper: :ucoffee: :uponder: Weisst Du, es gibt Hacks. Dann gibt es üble Hacks. Und dann gibt es noch welche von der Sorte wie oben...

Der Architekt hat es einfach: Mann nehme ein bisschen von dem da, mische dies mit ein bisschen von das da, und tue es schnell dorthin da. Nach dem Motto: Do here some magic, do there some magic...

Aber dieses "magic" hat es eben in sich. Die Coda ähh... die Coder müssen sich dann eben um die kleinsten Details kümmern, die mitunter fast unüberwindbar werden können. Deshalb gibt es Hacks. In gewisser Weise ist E = mc^2 schon ein "Hack" (da nicht allgemeingültig, z.B. subatomare Dimensionen) wenn wir davon ausgehen, dass die allgemeine Definition eines Hacks das Folgende ist: Vereinfachte (die ausdrücklich nicht allgemeine) Form einer Lösung die nur auf einen (mehr oder minder) beschränkten Definitionsbereich anwendbar ist.

Wenn man "garantieren" kann (d.h den Definitionsbereich genau angeben kann) das die Werte immer innerhalb der selbst definierten Grenzen liegt, darf meines Erachtens schon mal ein "Hack" angewandt werden, oder?

zeckensack
2006-01-17, 20:48:58
In der Zeit in der man Hacks dieses Kalibers erfindet, hätte man sich auch in eine Sprache einarbeiten können in der man sich nicht mit zusammengebundenen Schuhen fortbewegen muss.

Wenn man gottverdammte Assembler-Kenntnisse braucht um irgendwas in VB6 zu machen, dann geht das IMO eindeutig zu weit.

Der C-Wrapper hatte ja noch eine gewisse schlichte Eleganz. Aber auch dafür braucht man wiederum, tata, C-Kenntnisse.

Die richtig armen Schweine sind nichtmal mehr die die sich solche Hacks ausdenken (vllt weil sie vom "Chef" "gezwungen" werden mit VB6 zu arbyten, oder Langeweile haben etc), sondern die sie von irgendwo abschreiben ohne sie zu verstehen.

Juerg
2006-01-18, 09:35:43
Womit wir eigentlich wieder beim Ausgangspunkt wären, nicht? Wie ich schon mehrfach darauf hingewiesen habe, sollte heute keiner mehr mit VB anfangen, da dies das "COBOL der Neunziger-Jahre" sein wird. Dies geht alle, an ob kurz- oder weitsichtig, d.h. alle Linsen- und sowie auch Brillenträger.

Brillenschlange92
2006-01-18, 16:51:34
[gelöscht]