New version OCXOCX issues in Gb32

[Roger Cabo]

Hi,

I have some troubles with the new gb32 version and ocxoc  xxxx ...
Every time I press F5 I got an error.

Did you have the sameissue in windows 10 ? I'm on windows 7 currently.

Thank you..

Attachments:

gfabug.G32 (769 B)

[dragonjim]

Hi Roger,

I can confirm the problems using a cut down of the same code, although in my case it would raise a variable warning, then the next time it would work, then it would raise a variable warning, then run OK..... Sometimes it would raise two variable warnings then run the third time. Most odd.

For anyone else who would like to try to see if they get the same result, here is the code I used:

$Library "gfawinx"
$Library "UpdateRT"
UpdateRuntime      ' Patches GfaWin23.Ocx

OpenW Center 1, , , 1200, 700
Ocx Frame Frm = "Frame 1", 10, 10, 1000, 500
InitForm_Suchen(Frm)
Do : Sleep : Until Win_1 Is Nothing

Proc InitForm_Suchen(OB As Control)
 
 Dim x% = 240 / 15
 Dim y% = 1200 / 15
 Dim i% = 0, idx% = 0
 
 For i% = 0  To 1
   OcxOcx OB TextBox TXB_Nachname(idx%) = "", x%, y%, 200, 26
   TXB_Nachname(idx%).BorderStyle = 1
   idx%++
   OcxOcx OB TextBox TXB_Nachname(idx%) = "", x% + 224, y%, 209, 26
   TXB_Nachname(idx%).BorderStyle = 1
   idx%++
   y += 57
 Next i%
 
EndProc


It makes no difference if you include the two Library calls or not.

Did this happen with previous versions of GFABASIC?

[Roger Cabo]

Thanks for the reply..
If you use the form variable directly in the ocxocx command then it works.


Proc InitForm_Suchen()

Dim x% = 240 / 15
Dim y% = 1200 / 15
Dim i% = 0, idx% = 0

For i% = 0 To 1
   OcxOcx frm TextBox TXB_Nachname(idx%) = "", x%, y%, 200, 26
   TXB_Nachname(idx%).BorderStyle = 1
   idx%++
   OcxOcx frm TextBox TXB_Nachname(idx%) = "", x% + 224, y%, 209, 26
   TXB_Nachname(idx%).BorderStyle = 1
   idx%++
   y += 57
   Next i%
EndProc



Perhaps there is a logical issue in OcxOcx OB TextBox TXB_Nachname(idx%) = "", x%, y%, 200, 26
OB must be a unique static address.

Hmm... Seems it does not work in previous version as well.

[dragonjim]

I thought that OB might be the problem (although I can not find OB in the reserved word list), so I changed it to OBx and this made no difference either...

So I tried passing the Frame explicitly ByRef and ByVal but this made no difference either...

So I tried passing OB as a Frame, then a Variant, then an Object but no joy.

OcxOcx is not very tolerant - I have had problems with 'Array OCXs' (so OcxOcx fr(1) TextBox txt1 may also return a Variable error, even if Frame fr(1) has been defined, but not always).

For this reason, I think this is a syntax check problem (oversensitive or not updated to cope with later additions) rather than a compiler error, as your code does work every second or third try.

For that reason, it may be a good idea to pass this on to Sjouke, so this is what I have done...

[dragonjim]

As suspected, OcxOcx is very fussy about the control referenced: it must be a global (not local) variable linked to the original definition or declaration of the control (e.g. Ocx Frame Fr ...), not a parameter or a secondary global variable (e.g. Set NewFr = Fr).

There are a number of limitations with Ocx controls where, I suspect, they were not developed fully before GFA went out of business (for example, Message and MessageProc Subs do not work with Ocx Forms in an Ocx Array) and I suspect that this may be the case here too.

[Roger Cabo]

Subs do work with Ocx Forms in an Ocx Array for me.
I use this all the time.

OcxOcx Frm1 Label ClickLabel3(0) = "X", 30,30,100,100
OcxOcx Frm1 Label ClickLabel3(1) = "X", 30+100,30,100,100
OcxOcx Frm1 Label ClickLabel3(5) = "X", 30+200,30,100,100

Sub Label2_Click(Index%)
Msgbox Index%
EndSub

[dragonjim]

Hi Roger,

Sorry, my post was not as clear as it should have been. Ocx's in arrays work OK if the are paired to an object using OcxOcx...problems CAN (but do not always) arise when using Ocx arrays as the parent. For example:

Ocx Frame frm(1) ...
OcxOcx frm(1) TextBox txt1 ...

Please note that this does not always happen but, from personal experience, errors can creep in to long program listings - or as the program gets longer - so it is worth keeping in mind. It is similar to what used to happen with the Form() array before Sjouke fixed that problem.

In other words, it is best to use a dedicated, global, non-(Ocx) array variable which is declared using the Ocx command to avoid problems like you have experienced further down the road.