I've been working on a database project and have come across something I can't solve.

I have declared (in a separate module) the following:       Public arrName[4000] As String

In my Main form coding, I can reference this array just fine. The program compiles and runs with no error except when I try to put anything INTO the array. I always get an error telling me the array is Read-Only.

Is there something I have to do to declare them read/write? The documentation on arrays and their declarations is very confusing. I've tried all sorts of things like making them STATIC, and putting them in a Class instead of a module, but they all give me some sort of error when I try to use them.

The ultimate goal is to be able to access the main array system from any module or form. In VB6 we could use the Global keyword. I thought that in Gambas, the keyword "Public" made it available to everything. It does, but read-only?

Bill

 Ok. I've moved everything into a single Main module. The arrays are STILL read only at runtime.


EDIT: (two hours later). I seem to have found the answer. I added a "new" following the "As" and now I can refer to them as both read and write.

Now, if I can just figure out how to refer to a textbox on the main form from another form's code, I'll be happy. "frmMain.txtWhatever.text" causes a "don't know what this is" error when executed from another form's code.

Bill

issboss said

…Now, if I can just figure out how to refer to a textbox on the main form from another form's code, I'll be happy….

Yes, that is because form controls are Private by default.

One solution is to go to menu Project > Properties… > Options
…and then enable "Form controls are Public"

You should then be able to use…


…from another form.

I think there is another way to do this, but will have to make myself a cuppa tea while I try to remember…

One solution is to go to menu Project > Properties… > Options
…and then enable "Form controls are Public"

I didn't know that one.  :shock:

There is another way.  :arrow: There is a 'Public' property in the IDE you can change for individual controls

<IMG src="http://www.cogier.com/gambas/TextBox.png"> </IMG>

Going to get a cup of tea now… 8-)

stevedee said

…I think there is another way to do this…

If you don't want to make your controls Public, just create a Public routine in the 1st form:-


…then call it from your 2nd form:-


…which will update the textbox called txtName on the 1st form.

cogier said

…There is a 'Public' property in the IDE you can change for individual controls…

Nice one Charlie, I hadn't spotted that.


I guess if we were bothered about OOP and the concept of encapsulation, then keeping all controls Private and just having Public routines to Get & Set values would be the way to go. The great thing about programming for personal use is that you can please yourself.

stevedee said

 . . . . The great thing about programming for personal use is that you can please yourself.

How right you are, Stevedee.

I went over all the switches in the project properties and never once tumbled to the "make controls public". I bet I read it 10 times. What I'm doing is converting a rather massive DB program I wrote in VB6 into Gambas. Slow going, though. The similarities are what turns out to be the toughest to translate. Go figure.

When/if I get it finished, I'll see about putting it up in the Farm as a Multimedia Database for DVD's, vinyl/reel-to-reel tapes and records, and other items that fit the generic interface.

Thanks to you both.

Bill

 I believe I’ve read somewhere that Steve’s method is the recommended way, and that setting everything public should be avoided as far as possible. Using properties is also something to consider.

I think this is your issue:

[Gambas-user] Write protected array

You can work around this bug right now by turning your embedded array
declaration

  Public sortname_LOGO[9, 2] As String

into a real array

  Public sortname_LOGO As New String[9, 2]

And why are you using embedded arrays in the first place? Normal arrays
have many advantages over embedded arrays, such as:

• • they can grow and shrink dynamically,
  • their lifetime is not bound to the containing object,
  • they can be local variables.

The only virtue of embedded arrays is that they are placed compactly
inside the containing object, making them suitable to interact with
native libraries. If you are not doing that, embedded arrays should
be avoided. There is no reason to use them. Although this advice has
nothing to do with this particular bug here.

Regards,
Tobi

Personally, I've only used embedded arrays inside of structures to pass to shared libraries.

Ced

 I read the Wiki several more times before I tumbled onto Real arrays and changed my definitions to ones like this:

Public arrName as New String[intMaxSize]    (Where intMaxSize was set at the beginning as an Integer Constant = 4000)

They are now performing very well for me–reachable from every module. My immediate goal is to transcribe the VB6 program and make it workable in Gambas, THEN go back and make it more efficient. Along the way I've been learning a great deal about Gambas and how it works. In many ways better then VB.

Bill

jornmo said

I believe I’ve read somewhere that Steve’s method is the recommended way, and that setting everything public should be avoided as far as possible…

Its a security thing. <COLOR color="#BF0000">>>>>Ooops, see edit below</COLOR>

Imagine that cogier releases an update to "Killer App" to his fan base of 10 million users. He makes lblStatus Public so he can write status messages from any of the applications forms.

Someone discovers this and finds a way to write:-

lblStatus.Text = "Virus Alert - go to http:/ /hell.com/FixMe"


However, by keeping lblStatus Private, and using a routine to set the contents of lblStatus, it is possible to apply filters:-



<COLOR color="#BF0000">*****EDIT: After writing this early this morning, I have spent a couple of hours looking for validation.</COLOR>

I had thought (from my VB6/Windows days) that "Publics" could be manipulated in some way from outside the program, but have failed to find any evidence to support this, or any security related issues.

So if that is the case, I can't see why Gambas Controls can't be Public, especially as they need to be qualified by their parent (e.g. Form1.txtName.Text)

Imagine that cogier releases an update to "Killer App" to his fan base of 10 million users.

Imagine……

cogier said

Imagine that cogier releases an update to "Killer App" to his fan base of 10 million users.

Imagine……

10 million, that's all? Must not have been a very good app!  

     This is one of my favorite forums.

Bill

Another option is to use a module. I name mine Global so I know that I am using a global variable. You can pass variables to any form with this method without having to declare public variables.


Just enter some text in the first textbox then click the button to open Form2.  The text you entered in the textbox in FMain will be in the textbox in Form2.  Enter text again in the text box in Form2 then click the button to return to FMain.  Now textbox2 will contain the text you entered on Form2.  It's actually a simple way to pass variables that can be accessed from any form.

cage said

Another option is to use a module. I name mine Global so I know that I am using a global variable. You can pass variables to any form with this method without having to declare public variables.

Just enter some text in the first textbox then click the button to open Form2.  The text you entered in the textbox in FMain will be in the textbox in Form2.  Enter text again in the text box in Form2 then click the button to return to FMain.  Now textbox2 will contain the text you entered on Form2.  It's actually a simple way to pass variables that can be accessed from any form.

Yep, same here. Except I call mine MGlobal.      Makes it really handy to have all the global variables in one place.

 I agree completely about Global. Every one of my VB programs had a Global.bas module in it. I also put my Utilities in another and the Communications (if any) in another. It was during the initial translation process I got tangled up  in the intricacies of different methods for different languages. I'm pretty much out of the woods now and simply tying up loose ends. This has been an interesting thread for me.

Bill