Allgemeine Fragen zur PROFAN Programmierung
Views (Heute): 249111 (10547)
  Suchen
 Zurück zur Übersicht
 AutorThema: CombineRgn nicht unter XP ?
Mischa Brandt
Datum:07.03.02 04:23 Antwortenals Email verschicken (mischabrandt@gmx.de) 


Irgendwie scheint die CombineRgn Funktion unter
WindowsXP nicht mehr zu laufen (bzw SetWindowRgn in Kombination mit CombineRgn?)

Wenn ich ein einfaches Polygon, Rect, usw setzen will, kein Problem.

Kombiniere ich mehrere gehts nimmer?

Andreas, Du hast doch die rgntest.dll nochmal für XP geupt.
Dann könntest Du mir eventuell sagen, welche Alternative es gibt? Wäre ganz nett. Aber bitte sag nicht: "Benutz doch meine Dll!" :-)
Die finde ich zwar klasse, aber ich lerne doch noch viel lieber was dazu. :-) :-)

Danke im voraus,
Mischa


Andreas Miethe
Datum:08.03.02 08:20 Antwortenals Email verschicken (andreas@andreas-miethe.de) 


Hallo Mischa,

da machst Du wohl irgenwo einen Fehler !
das folgende Beispiel funktioniert auch mit XP, wie die Dll auch !

Gruss
Andreas

'-----------------------------------------------------
DEF CreateEllipticRgn(4) ! "GDI32","CreateEllipticRgn"
DEF CreateRectRgn(4) ! "GDI32","CreateRectRgn"
DEF CombineRgn(4) ! "GDI32","CombineRgn"
DEF SetWindowRgn(3) ! "USER32","SetWindowRgn"

Declare DestRgn&,SourceRgn1&,SourceRgn2&
SetTrueColor 1
WindowStyle 240
CLS

DestRgn& = CreateRectRgn(0,0,0,0)'Dummy
SourceRgn1& = CreateRectRgn(0,0,180,250)'Quellregion 1
SourceRgn2& = CreateEllipticRgn(80,200,320,420)'Quellregion2
CombineRgn(DestRgn&,SourceRgn1&,SourceRgn2&,2)'RGN_OR
SetWindowRgn(%hwnd,DestRgn&,1)
cls rgb(192,0,0)
Waitinput
DeleteObject Destrgn&
DeleteObject SourceRgn1&
DeleteObject SourceRgn2&
End
'-----------------------------------------------------



Mischa
Datum:08.03.02 20:36 Antwortenals Email verschicken  


Hallo!

Danke für die Antwort!
Alerdings habe ich mich mal wieder unpräzise ausgedrückt.
(ist ja nicht das erste mal, grrmpf!)

Ich meinte die mehrfache Verwendung von 'CombineRgn'
Da hakt es. :-)

Es geht aber notfalls ja auch über Pfade ('BeginPath'..) usw.
Trotzdem ist es mir immer noch ein Rätsel, wieso Deine dll so verflixt schnell arbeitet. Eine Pixel-weise Analyse des Bitmap-Dcs kann da ja wohl nicht die Grundlage sein?

Mischa


Andreas Miethe
Datum:12.03.02 10:59 Antwortenals Email verschicken (andreas@andreas-miethe.de) 


Hallo Mischa,

Es geht nur ueber die Einzelanlyse der Pixel !
Ich habe die Dll-Funktion mal nach Profan portiert, damit Du Dir das mal anschauen kannst.

www.ampsoft.de/daten/bitmaprgn.zip

Die Dll arbeitet zwar nicht ganz so, aber das Prinzip ist gleich.

Gruss
Andreas


Andreas Miethe
Datum:12.03.02 11:01 Antwortenals Email verschicken  


Schon wieder Http vergessen.

http://www.ampsoft.de/daten/bitmaprgn.zip


Mischa
Datum: 16.03.02 23:21 Antwortenals Email verschicken  


Hi Andreas!

Danke für den Quelltext. :-)

Das Beispiel produziert bei mir unter Win98 zwar nur ein rotes
Rechteck, ist aber egal, da der Text ja auch ohne Aufruf deutlich macht wie's läuft.

Ich habe allerdings schon vorher ein nahezu identisches Beispiel in einer anderen Basic-Programmiersprache geschrieben, von der man sagt, sie sei fast so schnell wie Assembler. Und da man mit ihr auch dll's progen kann, dachte ich, es wäre nett, ein paar Funktionen, die Tempo brauchen zu vereinigen. Allerdings ist es nach Deinem Beispiel zu urteilen, doch nur 'fast' so schnell, oder besser gesagt zu langsam für so was, wie freie Fensterformen. Na ja, diese Thematik ist ja nicht wirklich sooo wichtig... ;-)
Mich hatte es nur interessiert, weil ich kurz bevor Deine dll kam, ein eigenes Prog in Profan geschrieben hatte, mit dem man die Bilder zwar pixelweise, wie bei Dir ausliest, dabei allerdings Polygone berechnet , die dann in einen Bereich geschrieben werden. Dieser Bereich wird samt Bild (in jpg-Form) in einer kleinen Datei gespeichert.
Das Laden und verarbeiten der Datei ist nicht wesentlich langsamer als Deine dll, aber das erstellen.. wie Profan halt so is.. :-)
Deswegen interessierte mich das halt, da ich die Vermutung hatte, das die Basis Deines Werks evtl. auch polygonaler Natur sein könnte.
Aber so ist es wohl sinnvoller, ich überlasse solche Sachen erst mal den 'Maschinen-Sprachlern'
Ich konzentriere mich derweil auf Projekte, die nicht an der Geschwindigkeitshürde scheitern und dope diese dann mit Erweiterungen wie Deiner, oder Franks, .. Da gibts ja genug Möglichkeiten. Ist zwar Patchwork, aber es hilft dem gebrechlichen Profan ausreichend auf die Beine. ;-)
Ist nicht bös gemeint, Roland, ich benutzt Profan ja schließlich noch (und das sehr gerne), aber es ist nun mal eine Programmiersprache, die ohne externe Hilfen (siehe Prospeed, usw.) eher für Büroanwendungen und ähnliches geeignet ist. Für echtes Multimedia ist es zu lahm.
Na ja, letztendlich sind ja auch die 'schnellen' Spiele gemixt aus z. B. C++ und ASM, warum dann nicht auch Profan und ProSpeed, oder so. *g*

Nun denn,
nochmals Danke Andreas.

Gruß,
Mischa


 Zurück zur Übersicht