Obiekt poprzez OpenArgs ? Tak! (prawie...)
Krzysztof Naworyta
Tym razem ObjPtr() ...
Czy można przekazać obiekt poprzez OpenArgs ? Pewnie, że Nie !
przecież to string !
No właśnie.
Teoretycznie można by przekazać np. nazwę formularza ...
No ale jeśli mamy otwartych kilka instancji ?
Wtedy możemy posiłkować się niestandardowymi właściwościami i traktować
wołany formularz jako klasę
Dim f As Access.Form
DoCmd.OpenForm "form1"
Set f=Forms!form1
Set f.PrzekazywanyArgument = Me
No fajnie, ale to niestety wymusza zrezygnowanie z wywołania acDialog, które
przerywa wykonywanie procedury.
Można posiłkować się pętelką z DoEvents - aby symulować przerwanie kodu.
Ale jeśli jedyna "niestandardowa właściwość" jaką chcemy przekazać do
formularza, to kontrolka, która ma oczekiwać na zwróconą wartość ? Tak by
się chciało przekazać ją przez OpenArgs ...
No to jest !
Formularz 1 (pole tekstowe Tekst1, przycisk Polecenie1)
'******************************************************************
Private Sub Polecenie0_Click()
Dim oData As Object
Set oData = Me
DoCmd.OpenForm "Drugi", WindowMode:=acDialog, OpenArgs:=ObjPtr(oData)
MsgBox "ok"
Set oData = Nothing
End Sub
'******************************************************************
Formularz 2 ("Drugi")
(pole tekstowe Tekst2, przycisk Polecenie2)
'******************************************************************
Private Declare Sub CopyMemory Lib "KERNEL32" Alias "RtlMoveMemory" _
(Destination As Any, _
Source As Any, _
ByVal Length As Long)
Dim loData As Object
Private Sub Form_Open(Cancel As Integer)
Dim lngPointer As Long
On Error GoTo err_exit
lngPointer = CLng(Me.OpenArgs)
Call CopyMemory(loData, lngPointer, 4)
MsgBox loData.Name
Exit Sub
err_exit:
MsgBox "No OpenArgs"
Cancel = -1
End Sub
Private Sub Polecenie2_Click()
loData.Controls("Tekst1").Value = Me!Tekst2
Set loData = Nothing
DoCmd.Close
End Sub
'******************************************************************
Problemy:
1. Fajnie działa ale pod warunkiem, że po każdym wywołaniu zamknę formularz
wołający
(???)
W przeciwnym razie u mnie coś się dzieje nie tak
(Win2k, a'97 i a'2k - wylotka !)
2. Problem z kontrolkami (!) Wydawałoby się, że nie powinno być różnicy czy
przekazuje form czy Control, a jednak - chyba dlatego, że kontrolki nie są
oknami (?) odwołanie wskazuje na aktywną kontrolkę
(np. przycisk, zamiast na tekst1)
Być może czegoś nie wiem o ObjPtr
Zapraszam do testów, może razem coś się uda ...
źródło:
http://groups.google.com/groups?&threadm=eBtxuz5WBHA.2184%40tkmsftngp05
--
KN
Krzysztof Naworyta
Użytkownik "Krzysztof Naworyta" <k.naw...@datacomp.com.pl> napisał
(...)
> Formularz 1 (pole tekstowe Tekst1, przycisk Polecenie1)
> '******************************************************************
> Private Sub Polecenie0_Click()
> Dim oData As Object
> Set oData = Me
>
> DoCmd.OpenForm "Drugi", WindowMode:=acDialog, OpenArgs:=ObjPtr(oData)
> MsgBox "ok"
> Set oData = Nothing
> End Sub
> '******************************************************************
>
>
> Formularz 2 ("Drugi")
> (pole tekstowe Tekst2, przycisk Polecenie2)
>
> '******************************************************************
> Private Declare Sub CopyMemory Lib "KERNEL32" Alias "RtlMoveMemory" _
> (Destination As Any, _
> Source As Any, _
> ByVal Length As Long)
>
> Dim loData As Object '<<< !!!!!!
Powyższa zmienna po zastosowaniu CopyMemory() wskazuje na TĘ SAMĄ zmienną z
formularza wołającego !
Ale przecież ma inny okres życia !!!
Umiera wraz z zamknięciem tego formularza ! Stąd wysypka Access'a !
>
> Private Sub Polecenie2_Click()
> loData.Controls("Tekst1").Value = Me!Tekst2
> DoCmd.Close '<<<<<<<<<<< TU UMIERA !
> End Sub
> '******************************************************************
>
No więc już wiem co robić - i działa doskonale z formularzami, kontrolkami,
co kto chce ...
(no - aż tak wielu testów nie robiłem ;-)
Jeszcze raz:
Formularz 1 ("Pierwszy")
(pole tekstowe Tekst1, przycisk Polecenie1)
Formularz 2 ("Drugi")
(pole tekstowe Tekst2, przycisk Polecenie2)
moduł w "pierwszy":
'******************************************************************
Private Sub Polecenie1_Click()
Dim oData As Object
Set oData = Me!Tekst1
DoCmd.OpenForm "Drugi", WindowMode:=acDialog, OpenArgs:=ObjPtr(oData)
' tu sobie spokojnie czeka na zamknięcie "drugiego"
MsgBox "ok"
End Sub
moduł w "drugi":
'******************************************************************
Private Declare Sub CopyMemory Lib "KERNEL32" Alias "RtlMoveMemory" _
(Destination As Any, _
Source As Any, _
ByVal Length As Long)
Dim loData As Object
Private Sub Form_Open(Cancel As Integer)
Dim lngPointer As Long
On Error GoTo err_exit
If IsNull(Me.OpenArgs) Then
MsgBox "Formularz otwierany tylko z innych !"
Cancel = -1
Exit Sub
End If
lngPointer = CLng(Me.OpenArgs)
Call CopyMemory(loData, lngPointer, 4)
Me!Tekst2 = loData.Value ' ustaw wartość z przekazanej kontrolki
Exit Sub
err_exit:
MsgBox Err.Description
End Sub
Private Sub Polecenie2_Click()
loData.Value = Me!Tekst2 'przekaż wartość do formularza "pierwszy"
DoCmd.Close ' acForm, Me.Name
End Sub
Private Sub Form_Unload(Cancel As Integer)
On Error Resume Next
If loData Is Nothing Then
Debug.Print
Else
Call CopyMemory(loData, 0&, 4) ' ponownie przekieruj loData
' tym razem w Nothing,
' aby sobie mogła spokojnie umrzeć !
End If
End Sub
Działa doskonale także z wieloma instancjami "pierwszego":
moduł standardowy
'******************************************************************
Function test()
Static f1 As Form
Static f2 As Form
Set f1 = New Form_Pierwszy
f1.Visible = True
f1.Caption = "Pierwszy 1"
DoCmd.MoveSize 500, 500
Set f2 = New Form_Pierwszy
f2.Visible = True
f2.Caption = "Pierwszy 2"
DoCmd.MoveSize 500, 3000
End Function
Miłej zabawy
;-)
KN
Ryszard Halski
"Krzysztof Naworyta" <k.naw...@datacomp.com.pl> wrote in message
news:aobl3f$57d$1...@news.onet.pl...
> Miłej zabawy
> ;-)
jak chcesz to potrafisz, tego mi brakowało
KRH
Krzysztof Naworyta
> (...)
> > Formularz 1 (pole tekstowe Tekst1, przycisk Polecenie1)
> > '******************************************************************
> > Private Sub Polecenie0_Click()
> > Dim oData As Object
> > Set oData = Me
> > DoCmd.OpenForm "Drugi", WindowMode:=acDialog, OpenArgs:=ObjPtr(oData)
> > End Sub
> > '******************************************************************
> >
> > Formularz 2 ("Drugi")
> > (pole tekstowe Tekst2, przycisk Polecenie2)
> > '******************************************************************
> > Private Declare Sub CopyMemory Lib "KERNEL32" Alias "RtlMoveMemory" _
> > (Destination As Any, _
> > Source As Any, _
> > ByVal Length As Long)
> >
> > Dim loData As Object '<<< !!!!!!
>
> Powyższa zmienna po zastosowaniu CopyMemory() wskazuje na TĘ SAMĄ zmienną
z
> formularza wołającego !
> Ale przecież ma inny okres życia !!!
> Umiera wraz z zamknięciem tego formularza ! Stąd wysypka Access'a !
To oczywiście jedynie próba ujęcia "własnymi słowami" zaobserwowanych
objawów,
bo ich fizycznego sensu czy przyczyn nie pojmuję ...
> > Private Sub Polecenie2_Click()
> > loData.Controls("Tekst1").Value = Me!Tekst2
> > DoCmd.Close '<<<<<<<<<<< TU UMIERA !
> > End Sub
> > '******************************************************************
(...)
Dlaczego "śmierć" zmiennej loData (w wołanym formularzu) powoduje śmierć
zmiennej oData (w formularzu wołającym ?)
A może wręcz destrukcję obiektu do którego ta zmienna się odwołuje ?
(wylotka Access'a)
> Call CopyMemory(loData, 0&, 4) ' ponownie przekieruj loData
> ' tym razem w Nothing,
> ' aby sobie mogła spokojnie umrzeć !
A powyższe to po prostu próba odwrócenia tych dziwnych objawów - i co mnie
niezmiernie cieszy: próba udana !
Być może prawidłowe zrozumienie obiektów i wskaźników do nich pozwoliłoby
użyć innej funkcji niż CopyMemory, albo użyć ją inaczej, aby w efekcie
uzyskać niezależność zmiennych.
Przecież w "normalnym" kodzie:
Set A = Me!Text1
(...)
Set B = A
"śmierć" B nie powoduje "zabicia" A (!)
Będę zobowiązany za bardziej "naukowe" wyjaśnienie tego, co z racji
nieznajomości języka C nie ogarniam ...
--
KN
P.S.
Ale tak poza tym to strasznie mi się to rozwiązanie podoba :-)
Być może nie należy go nadużywać (?) ale nagle "głupkowate" OpenArgs daje
nieograniczone możliwości przekazywania zmiennych, bez uciekania się do
ogólnodostępnych w kodzie zmiennych globalnych.
Może jedynie poza tablicami tekstowymi, dla których, jeśli dobrze
zrozumiałem co piszą w
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q199824
należy stworzyć własną bibliotekę typów ...
Osobiście polubiłem już własne niestandardowe właściwości formularzy, ale
ciągle denerwowała mnie pętelka symulująca zatrzymanie kodu:
(Do: DoEvents: Loop While ...)
Szkoda, że choć access'owym formularzom można ustawić .Modal=True, to jednak
nie zatrzymuje to wykonania, tak jak robi to parametr acDialog metody
OpenForm.
Nadal nie wiadomo jak bez pętelki Do-Loop otwierać _wiele_ "dialogowych"
instancji wołanego formularza.
Ale może i nie ma takiej potrzeby ...
(albo podświadomie ją omijałem ;-)
No i na zakończenie "wada" metody OpenForm, o której warto przypomnieć ...
OpenArgs nie jest przekazywane do formularza już będącego otwartym.
W sumie nic niespodziewanego, zważywszy na nazwę parametru ;-)
ale łatwo o tym zapomnieć, wywołując ponownie OpenForm dla formularza tylko
ukrytego ...
Wtedy nie ma jak właściwość niestandardowa (czy po prostu publiczna zmienna
formularza)
--
Krzysztof Naworyta
(...)
> Private Sub Form_Unload(Cancel As Integer)
> On Error Resume Next
> If loData Is Nothing Then
> Debug.Print
> Else
> Call CopyMemory(loData, 0&, 4) ' ponownie przekieruj loData
> ' tym razem w Nothing,
> ' aby sobie mogła spokojnie umrzeć !
> End If
> End Sub
Właśnie wymyśliłem prostszy sposób (chyba bezpieczniejszy) na ominięcie
problemu z zmiennymi obiektowymi:
Dim loData As Object
Private Sub Form_Open(Cancel As Integer)
Dim lngPointer As Long
Dim tmpData As Object ' nowa zmienna pomocnicza
On Error GoTo err_exit
lngPointer = CLng(Me.OpenArgs)
Call CopyMemory(tmpData, lngPointer, 4) ' przechwyć obiekt
Set loData = tmpData ' przekaż do docelowej zmiennej
Call CopyMemory(tmpData, 0&, 4) ' zwolnij przechwyt
' i juz można śmiało korzystać z loData ...
(...)
End Sub
i juz nie trzeba dodatkowej procedury Form_Unload()
Nadal jednak wygląda to tajemniczo ...
--
KN
Raphael Posmyk
>
> i juz nie trzeba dodatkowej procedury Form_Unload()
> Nadal jednak wygląda to tajemniczo ...
No to wtrace moje 3 grosze.
1. VBA Engine posiada 'garbage collection' (gb), znaczy mechanism
samoczynnego zwalniania zasobow. Przeciez nie zawsze
musimy uzywac 'Set obj = Nothing' aby wymusic destrukcje
instancji danej klasy/typu. Zaluzmy, ze ow mechanizm
teoretycznie funkcjonuje.
2. Znienne nie sa niczym innym niz wskaznikami do obszaru
pamieci, gdzie przechowywane sa moje dane. Typ zmiennej
informuje VB-Engine jak interpretowac owe dane (ile
pamieci jest zajetej, jaka jest struktura danych zapamietanych
w komorce/komorkach pamieci wskazywanej przez moja zmienna.
3. Uzycie konstruktu:
Set A = Me!Text1
(...)
Set B = A
powoduje, ze VB-engine wykonuje kopie (B) wskaznika do A.
Mamy zatem dwie zmienne/referencje/wskazniki do tej
samej struktury w pamieci. Co wazniejsze informuje gb,
ze istnieje kolejna referencja do A. Znaczy zniszczenie
B (set B = nothing) nie powoduje zniaszczenia A.
4. Co sie stalo u Ciebie ? Wartosc loData zostala
przypisana przy pomocy funkcji Win32-API
(Call CopyMemory(loData, lngPointer, 4), Twoja pierwsza
proba), czyli jakgdyby obszedles VB-engine i gb.
Co za tym idzie gb nie wie, ze istnieje kolejna
referencja do formatu wolajacego. Dalej, loData jest
zmienna lokalna i jest niszczona po opuszczeniu kontextu
Form_Open() a glupi gb niszczy wolajacy format bo nie wie
o istnieniu innych referencji - Bang !
5. Co sie dzieje gdy zadeklarowales loData globalnie
(Twoj ostatni posting) ?
> Dim loData As Object
>
> Private Sub Form_Open(Cancel As Integer)
> Dim lngPointer As Long
> Dim tmpData As Object ' nowa zmienna pomocnicza
>
> On Error GoTo err_exit
>
> lngPointer = CLng(Me.OpenArgs)
> Call CopyMemory(tmpData, lngPointer, 4) ' przechwyć obiekt
> Set loData = tmpData ' przekaż do docelowej zmiennej
> Call CopyMemory(tmpData, 0&, 4) ' zwolnij przechwyt
>
> ' i juz można śmiało korzystać z loData ...
> (...)
> End Sub
Rozwiazanie tkwi IMHO w 'Set loData = tmpData'. W ten
sposob informujasz vb-engine, ze istnieje kolejna referencja
do wolajacego formatu. W ten sposob destrukcja loData nie
spowoduje destrukcji (zmiennej do) formatu wolajacego.
Dzieki 'Set loData = tmpData)' powyzsze powinno dzialac
nawet wtedy gdy loData bedzie zadeklarowane lokalnie w
Form_Open() (?!)
Ciao, Rafal
P.S. A moze to wszystko jest jednak calkiem inaczej ;-)
Krzysztof Naworyta
(...)
> 1. VBA Engine posiada 'garbage collection' (gb), znaczy mechanism
> samoczynnego zwalniania zasobow. Przeciez nie zawsze
> musimy uzywac 'Set obj = Nothing' aby wymusic destrukcje
> instancji danej klasy/typu. Zaluzmy, ze ow mechanizm
> teoretycznie funkcjonuje.
(...)
> powoduje, ze VB-engine wykonuje kopie (B) wskaznika do A.
> Mamy zatem dwie zmienne/referencje/wskazniki do tej
> samej struktury w pamieci. Co wazniejsze informuje gb,
> ze istnieje kolejna referencja do A. Znaczy zniszczenie
> B (set B = nothing) nie powoduje zniaszczenia A.
(...)
> 4. Co sie stalo u Ciebie ? Wartosc loData zostala
> przypisana przy pomocy funkcji Win32-API
> (Call CopyMemory(loData, lngPointer, 4), Twoja pierwsza
> proba), czyli jakgdyby obszedles VB-engine i gb.
> Co za tym idzie gb nie wie, ze istnieje kolejna
> referencja do formatu wolajacego. Dalej, loData jest
> zmienna lokalna i jest niszczona po opuszczeniu kontextu
> Form_Open() a glupi gb niszczy wolajacy format bo nie wie
> o istnieniu innych referencji - Bang !
Nowe dla mnie pojęcie gb - ale w zasadzie wiele wyjaśnia ...
A przynajmniej lepiej nazywa "nieznane" ;-)
> 5. Co sie dzieje gdy zadeklarowales loData globalnie
> (Twoj ostatni posting) ?
>
> > Dim loData As Object
To nie jest zmienna globalna, lecz zmienna prywatna na poziomie modułu
wołanego formularza.
Przecież chcę z niej korzystać, a Form_Open służy jedynie do jej inicjowania
...
Ale to szczegół. Niemniej gdyby to miała być zmienna globalna, to po co te
wszystkie sztuczki z ObjPtr i CopyMemor ?
;-)
> Rozwiazanie tkwi IMHO w 'Set loData = tmpData'. W ten
> sposob informujasz vb-engine, ze istnieje kolejna referencja
> do wolajacego formatu. W ten sposob destrukcja loData nie
> spowoduje destrukcji (zmiennej do) formatu wolajacego.
> Dzieki 'Set loData = tmpData)' powyzsze powinno dzialac
> nawet wtedy gdy loData bedzie zadeklarowane lokalnie w
> Form_Open() (?!)
IMHO najważniejsze w tym wszystkim jest
Call CopyMemory(tmpData, 0&, 4)
bo bez tej linijki access nadal będzie się zawieszał w momencie innej -
naturalnej "śmierci" tmpData.
Najzabawniejsze, że chłopak od którego "zdjąłem" przepis na
OpenArgs=ObjPtr(zm) ani się nie zająknął na ten temat.
Poszukiwania innych wątków z ObjPtr skończyły się fiaskiem (na grupach
*access*)
Dzięki za podparcie teoretyczne
--
KN
Raphael Posmyk
> Nowe dla mnie pojęcie gb - ale w zasadzie wiele wyjaśnia ...
> A przynajmniej lepiej nazywa "nieznane" ;-)
<ot>
Kiedys na jakiejs grupie dyskutowano jakie baloby
najtrafniejsze tlumaczenie dla 'garbage collector'.
Ktos podal 'smieciarz'. Tak mi sie spodobalo, ze
nie sledzilem dalej tego watku aby nie psuc sobie
radochy. Tak samo jak szukano (dawno temu) polskiej
nazwy dla odtwarzaczy CD-Audio. Moim faworytem byl
'swiatlograj' :-}
</ot>
>>5. Co sie dzieje gdy zadeklarowales loData globalnie
>> (Twoj ostatni posting) ?
>>
>> > Dim loData As Object
> To nie jest zmienna globalna, lecz zmienna prywatna na poziomie modułu
> wołanego formularza.
Masz racje. Tym 'globalnie' chcialem tylko podkreslic, ze
jest poza kontekstem Form_Open().
>> Rozwiazanie tkwi IMHO w 'Set loData = tmpData'. W ten
>> sposob informujasz vb-engine, ze istnieje kolejna referencja
>> do wolajacego formatu. W ten sposob destrukcja loData nie
>> spowoduje destrukcji (zmiennej do) formatu wolajacego.
>> Dzieki 'Set loData = tmpData)' powyzsze powinno dzialac
>> nawet wtedy gdy loData bedzie zadeklarowane lokalnie w
>> Form_Open() (?!)
> IMHO najważniejsze w tym wszystkim jest
> Call CopyMemory(tmpData, 0&, 4)
> bo bez tej linijki access nadal będzie się zawieszał w momencie innej -
> naturalnej "śmierci" tmpData.
Jezeli zachowac kolejnosc:
Set loData = tmpData
Call CopyMemory(tmpData, 0&, 4)
powinno, w/g mojego teoretyzowania, dzialac takze przy uzyciu
Set loData = tmpData '-- A
Set tmpData = Nothing
Dzieki linii A, vb-engine powinno rozpooznac, ze jest
wiecej niz jedna referencja do 'wolajacego formatu'
(tu loData) i nie niszczyc go. Jesli tak nie jest
to ja jestem ..., albo to wszystko przez M$ ;-)
Egal, masz "running system"
Ciao, Rafal
Krzysztof Naworyta
> >> Rozwiazanie tkwi IMHO w 'Set loData = tmpData'. W ten
> >> sposob informujasz vb-engine, ze istnieje kolejna referencja
> >> do wolajacego formatu. W ten sposob destrukcja loData nie
> >> spowoduje destrukcji (zmiennej do) formatu wolajacego.
> >> Dzieki 'Set loData = tmpData)' powyzsze powinno dzialac
> >> nawet wtedy gdy loData bedzie zadeklarowane lokalnie w
> >> Form_Open() (?!)
>
> > IMHO najważniejsze w tym wszystkim jest
> > Call CopyMemory(tmpData, 0&, 4)
> > bo bez tej linijki access nadal będzie się zawieszał w momencie innej -
> > naturalnej "śmierci" tmpData.
>
> Jezeli zachowac kolejnosc:
>
> Set loData = tmpData
> Call CopyMemory(tmpData, 0&, 4)
>
> powinno, w/g mojego teoretyzowania, dzialac takze przy uzyciu
>
> Set loData = tmpData '-- A
> Set tmpData = Nothing
>
> Dzieki linii A, vb-engine powinno rozpooznac, ze jest
> wiecej niz jedna referencja do 'wolajacego formatu'
> (tu loData) i nie niszczyc go. Jesli tak nie jest
> to ja jestem ..., albo to wszystko przez M$ ;-)
>
A jednak Twoje przypuszczenia nie sprawdziły się !
Poprzez CopyMemory dochodzi do ustawienia niepokojącej tożsamości między
Me.Tekst1 (w jednym formularzu) a tmpData (w drugim)
i jedynie
Call CopyMemory(tmpData, 0&, 4)
rozwiązuje to pieprzone "powiązanie", zabezpieczając przed wylotką na skutek
wcześniejszej "śmierci" tej drugiej.
To, czy w międzyczasie utworzę N innych odwołań, zupełnie nie ma wpływu na
tę tajemniczą "tożsamość".
--
KN
Raphael Posmyk
>>>IMHO najważniejsze w tym wszystkim jest
>>>Call CopyMemory(tmpData, 0&, 4)
>>>bo bez tej linijki access nadal będzie się zawieszał w momencie innej -
>>>naturalnej "śmierci" tmpData.
>>Jezeli zachowac kolejnosc:
>>
>> Set loData = tmpData
>> Call CopyMemory(tmpData, 0&, 4)
>>
>>powinno, w/g mojego teoretyzowania, dzialac takze przy uzyciu
>>
>> Set loData = tmpData '-- A
>> Set tmpData = Nothing
>>
>>Dzieki linii A, vb-engine powinno rozpooznac, ze jest
>>wiecej niz jedna referencja do 'wolajacego formatu'
>>(tu loData) i nie niszczyc go. Jesli tak nie jest
>>to ja jestem ..., albo to wszystko przez M$ ;-)
> A jednak Twoje przypuszczenia nie sprawdziły się !
To prawda. Przeciez tmpData powstalo przy uzyciu
CopyMemory, wiec nie moge tego zniszczyc przez
'Set tmpData = Nothing'. To wlasnie to ostatnie
wyprowadza vb-engine z rownowagi tak samo jak
automatyczne niszczenie tmpData przy opuszczeniu
kontekstu podprogramu (tu Form_Open()).
> Poprzez CopyMemory dochodzi do ustawienia niepokojącej tożsamości między
> Me.Tekst1 (w jednym formularzu) a tmpData (w drugim)
> i jedynie
> Call CopyMemory(tmpData, 0&, 4)
> rozwiązuje to pieprzone "powiązanie", zabezpieczając przed wylotką na skutek
> wcześniejszej "śmierci" tej drugiej.
>
> To, czy w międzyczasie utworzę N innych odwołań, zupełnie nie ma wpływu na
> tę tajemniczą "tożsamość".
Znalazlem artykul, ktory tlumaczy owa tajemniczą "tożsamość".
Niestety jest on w jez. niem.:
http://www.aboutvb.de/khw/artikel/khwptrtoobject.htm
Znaczy, wszystkie referencje tworzone przy uzyciu
CopyMemory (RtlMoveMemory) powinny byc w taki
sam sposob niszczone (przez przyporzakowanie
wskaznikowi wartosci 0&).
Interesujaca jest tam jednak jedna funkcyjka, ktora konwertuje
wartosc wskaznika (Long, czyli to co zwraca ObjPtr()) na Object:
Private Declare Sub CopyMemory Lib "kernel32" _
Alias "RtlMoveMemory" (dest As Any, source As Any, _
ByVal bytes As Long)
Public Function PtrToObject(ByVal iObj As Variant) As Object
Dim nObj As Object
If VarType(iObj) = vbLong Then
CopyMemory nObj, CLng(iObj), 4
Else
Exit Function
End If
Set PtrToObject = nObj
CopyMemory nObj, 0&, 4
End Function
Moze Ci sie przyda ? Biorac powyzsze pod uwage, powinien
teraz dzialac rowniez wariant, ktory probowales na samym
poczatku - przekazywanie wskaznika formantu (ObjPtr(Me)).
Inny ciekawy artykul znajdziesz pod adresem:
http://www.codeproject.com/useritems/how_to_do_pointers_in_visual_basic.asp
(polecam komentarze u dolu)
Ciao, Rafal
Krzysztof Naworyta
> Znalazlem artykul, ktory tlumaczy owa tajemniczą "tożsamość".
> Niestety jest on w jez. niem.:
>
> http://www.aboutvb.de/khw/artikel/khwptrtoobject.htm
uff, niemiecki mialem w liceum, ale nie odrabiałem lekcji ...
;-)
W sumie najważniejszy kod, który potwierdza mój przebłysk lamerskiego
geniuszu ;-))))
> Interesujaca jest tam jednak jedna funkcyjka, ktora konwertuje
> wartosc wskaznika (Long, czyli to co zwraca ObjPtr()) na Object:
>
> Public Function PtrToObject(ByVal iObj As Variant) As Object
tak, nie chwaląc też już ją sobie byłem w międzyczasie napisał ...
> Moze Ci sie przyda ? Biorac powyzsze pod uwage, powinien
> teraz dzialac rowniez wariant, ktory probowales na samym
> poczatku - przekazywanie wskaznika formantu (ObjPtr(Me)).
działa wszystko. Jedyne czego nie próbowałem to przekazanie instancji
własnych klas.
> Inny ciekawy artykul znajdziesz pod adresem:
>
http://www.codeproject.com/useritems/how_to_do_pointers_in_visual_basic.asp
Serdecznie dziękuję za linki i sekundowanie.
Link jest przeciekawy, ale czy jest sens próbować artykuł zrozumieć, nie
rozumiejąc do końca co to jest pointer ?
;-)
Ale czy to pierwszy raz cos stosuję, a dopiero po czasie zaczynam rozumieć
filozofię ?
;-))))
--
KN
P.S.
Czy oni tam Cię w tym Reichu aby wystarczająco szanują ?
Zatroskany
;-)
Raphael Posmyk
> Ale czy to pierwszy raz cos stosuj?, a dopiero po czasie zaczynam rozumie?
> filozofi? ?
> ;-))))
A nie nie ! Tu mamy regularny (z punktu widzenia 'software
enginerig') przypadek. Chciales przekazac z formantu 'wolajacego'
do formantu 'wolanego' referencje na objekt/formant wolajacy
(jako ze Form.Name formantu 'wolajacego' nie jest jednoznaczna).
Wystapil problem. Rozwiazales go. Zglebiles nature problemu.
Za kazdym nastepmym razem, podobna kwestia nie bedzie wiecej
problemem.
Przyznasz, ze to cos diametralnie innego niz: hej mam handle
do taskId i SysCmd(643), co by tu z tym ciekawego zrobic ???
;-)
> P.S.
> Czy oni tam Ci? w tym Reichu aby wystarczaj?co szanuj? ?
> Zatroskany
Odpowiadajac powierzchownie: Ustawilem sie. Doglebna odpowiedz
bylaby zbytnio OT i zbyt prywanta, aby ja przytaczac na forum
tej grupy. Jezeli chesz pogadamy na privi'ie.
Ciao, Rafal
Krzysztof Naworyta
> > Ale czy to pierwszy raz cos stosuje, a dopiero po czasie zaczynam
rozumiec
> > filozofie ?
> > ;-))))
>
> A nie nie ! Tu mamy regularny (z punktu widzenia 'software
> enginerig') przypadek. Chciales przekazac z formantu 'wolajacego'
> do formantu 'wolanego' referencje na objekt/formant wolajacy
> (jako ze Form.Name formantu 'wolajacego' nie jest jednoznaczna).
> Wystapil problem. Rozwiazales go. Zglebiles nature problemu.
> Za kazdym nastepmym razem, podobna kwestia nie bedzie wiecej
> problemem.
>
> Przyznasz, ze to cos diametralnie innego niz: hej mam handle
> do taskId i SysCmd(643), co by tu z tym ciekawego zrobic ???
> ;-)
:-))))))))))))
Ha, no i mylisz sie ! Nie mialem zadnego problemu (nie wspomne o tych
rzeczywistych, bo to by bylo dopiero OT ...)
- radzilem sobie przy pomocy Property Set, a modal zalatwialem "Loopem"
Gdzies w sieci nadzialem sie na InputBox i StrPtr i zaczelo sie grzebanie.
No i cos tam wygrzebalem i zaczalem sie zastanawiac jak to uzyc.
Jednym slowem czas zupelnie zmarnowany ... ;-))))
> > P.S.
> > Czy oni tam Cie w tym Reichu aby wystarczajaco szanuja ?
> > Zatroskany
>
> Odpowiadajac powierzchownie: Ustawilem sie. Doglebna odpowiedz
> bylaby zbytnio OT i zbyt prywanta, aby ja przytaczac na forum
> tej grupy. Jezeli chesz pogadamy na privi'ie.
Gratuluje !
Smak chleba na obczyznie znam - tym bardziej cieszy, ze Ci sie wiedzie
--
KN
Raphael Posmyk
> :-))))))))))))
>
> Ha, no i mylisz sie ! Nie mialem zadnego problemu (nie wspomne o tych
> rzeczywistych, bo to by bylo dopiero OT ...)
No to zle interpretowalem Twoj pierwotny posting w watku :-|
> No i cos tam wygrzebalem i zaczalem sie zastanawiac jak to uzyc.
> Jednym slowem czas zupelnie zmarnowany ... ;-))))
Chyba nie zmarnowany ? Ponieslismy obaj (i reszta grupy chyba tez)
nasze kwalifikacje. A jesli nawet byla to sztuka dla sztuki,
to lepiej tak niz siedziec i miezyc uciekajacy czas.
Ciao, Rafal
Piotr Lipski
sciemy w stylu PL
Inna sprawa, ze nie wszyscy beda umieli sie tym posluzyc (w domysle: JA bede
umial, ha!)
> nasze kwalifikacje. A jesli nawet byla to sztuka dla sztuki,
> to lepiej tak niz siedziec i miezyc uciekajacy czas.
Ja tam w wolnej chwili biere denature, kawalek chleba i jechane, a nie
jakies takie gupoty...
--
PL
Krzysztof Naworyta
>> No i cos tam wygrzebalem i zaczalem sie zastanawiac jak to uzyc.
>> Jednym slowem czas zupelnie zmarnowany ... ;-))))
>
> Chyba nie zmarnowany ? Ponieslismy obaj (i reszta grupy chyba tez)
> nasze kwalifikacje. A jesli nawet byla to sztuka dla sztuki,
> to lepiej tak niz siedziec i miezyc uciekajacy czas.
Co Wy, tam w Reichu, nie rozumiecie sie na usmieszkach ???
Jestem strasznie dumny z tego naszego watku - i wielkie dzieki za wspolprace
!!!
Realizacje sztuczek z StrPtr() i ObjPtr(), czyli watki:
- InputBox 08/10/2002
- OpenArgs
- EbExecuteLine (tylko a'97) - 12/10/2002
juz znalazly swoje miejsce w przykladowej bazie i czekaja w kolejce na
umieszczenie na stronie Krzyska Pozorka
Watek z podmiana wartosci stalej (Const is Const) juz sobie darowalem
(bo to z daleka smierdzi potencjalnym uszkodzeniem bazy czy bo ja wiem czym)
Jestem niemal pewien, ze OpenArgs i ObjPtr beda obecnie uzywane bardzo
czesto
(przynajmniej przez pewna grupe Kolegow)
Jeszcze raz dzieki za zaangazowanie.
Juz sie balem, ze ten watek umrze po dwoch pierwszych postach ...
--
KN