Runtime Revolution Ltd

RE: 2D and Multidimensional Arrays in Revolution 1.8

mokogobo — Thu, 24 Jul 2008 19:49:36 GMT

trevordevore wrote:

Looks can be deceiving

The key is still a string. If you check the keys of the array you will see something like "1,COLUMN".

The way Rev works you can write theArray[1, "COLUMN_NAME"] and everything works as intended in the end and I find it easier to read. Of course in 3.0 this is no longer necessary as you can write theArray[1]["COLUMN_NAME"].

Very cool. I appreciate your help.

RE: 2D and Multidimensional Arrays in Revolution 1.8

trevordevore — Thu, 24 Jul 2008 18:30:10 GMT

RE: 2D and Multidimensional Arrays in Revolution 1.8

mokogobo — Thu, 24 Jul 2008 18:24:54 GMT

I like the comma trick. I'm curious how this works. The array's index/key doesn't appear to be a string or an integer when using the comma method you described. What exactly is the index/key in this case?

Thanks.

RE: 2D and Multidimensional Arrays in Revolution 1.8

Bernard — Thu, 24 Jul 2008 17:22:42 GMT

I considered recommending that too Trevor, as that is what you use in libdatabase (libDatabase is a great way of working with databases from inside Rev: http://www.bluemangolearning.com/developer/revolution/)

RE: How-To: Non-Blocking DB/Interrnet operation

Bernard — Thu, 24 Jul 2008 17:19:19 GMT

Well, first of all, I'm not sure what your precise problem is. I just tried the internet tutorial you mentioned, and there was no problem for me - it's lightning fast, and there is no indication of any problem with the IDE slowing down. Maybe you are on a really slow internet connection (I'm on ADSL, so nothing really fast at this end). Maybe you have some other problem with your computer or with something else you have running in Rev. (For the record, I just tried the tutorial on an extremely cheap laptop I got that came with Vista pre-installed - I'd imagine any other computer purchased in the last 12 months would be faster than this).

Furthermore, I don't know what you are comparing Rev to. The last couple of days I had to use a Java program (from IBM no less), and every time I had to return to the program from looking something up in another window, the Java program would take as much as 30 seconds just to re-draw the buttons on the screen (only a few buttons and a few fields). Rev only behaves that way when something is seriously out of whack in the IDE (e.g. an endless loop, or a massive number of errors being fired off).

Jan gives you some good advice about using cursors. There are also callbacks, and the use of 'send in time'. My advice would be to start identifying some concrete issues you are having, and see if they are really issues with Rev or something else. Then start asking for advice in those concrete situations. I think you are going to find that a more productive route. If you are going to use Rev, you will need to think more in terms of an event-handling paradigm than a threading paradigm.

Your suggestion of using helper programs is not unheard of, but that route is something I would only consider when all else fails. I think that you need to find out why you are seeing such poor performance from e.g. the internet tutorial.

RE: menu bars in windows

stan — Thu, 24 Jul 2008 16:34:26 GMT

Cool - thanks Jan I'll give that a try

RE: How-To: Non-Blocking DB/Interrnet operation

Janschenkel — Thu, 24 Jul 2008 16:20:42 GMT

Hi Frank,

As a Java-developer, I understand your desire for multithreading capabilities in Revolution - however, they open up a huge can of worms for developers who mostly don't want to be bothered with low-level details. And while 'synchronized' is a lovely Java-keyword and the concurrency package has a whole bunch of classes to help, you can still get yourself into plenty of trouble.

That said, I would love it if more parts of Revolution followed the 'callback' paradigm that we have for socket communication. In the meantime, you can use a 'send in time' construct to allow user events to occur and the screen to redraw.

And for database access, my trick is to not use the 'revDataFromQuery' function to get all the data in one go, but use the 'revQueryDatabase' function instead to get a cursor, and then fetch the records + update the table field in blocks of 20 records using a 'send in time' construct.

Revolution is usually very fast, but smart developers take care of those situations where things take a little longer...

Jan Schenkel.

RE: menu bars in windows

Janschenkel — Thu, 24 Jul 2008 16:07:29 GMT

Once you've selected it in the Application Browser, click on the 'Edit group' button in the Revolution toolbar. That should get you into group edit mode, at which point you can add a ractangle graphic and give it the right size - you'll probably want to make it opaque and set its layer to the bottom, also using the inspector palette.

Jan Schenkel.

RE: How-To: Non-Blocking DB/Interrnet operation

fhx — Thu, 24 Jul 2008 15:11:52 GMT

Hi,

my question is: what to do in situations in which you know you need background processes that are blocking user activities, because they are taking so much time/resources; Revolution has no multi-threading capabilities. Which is pretty bad

I remember that i was using an example from the tutorial (Basic: Internet Images):http://runrev.com/developers/tutorials/basic-internet-images/ The internet communication has even slowed down the refreshing of Revolutions' IDE windows -- I reported this as a bug, but then I understood, that this is due to the principle weakness (!!!) of not having multi-threading capabilities.

This is pretty scary, if activities such as: file system, db or internet background processes could have such a huge impact on the user experience so even the refreshing of the interfaces could take seconds. The size of tasks are not always in the controil of the developer .. and sometime it is simply a precautions to put tasks into a thread in order to avoid these weird side-effects

I know I will have, beside internet activities, large file-system and DB activities which could take 20sec to 1 minute to be finished: I was considering to create a progress bar control from which these activities are initiated and could be used to inform the user that there are is no interactivity. thios progress bar control could segment these activities in smaller chunks, but lets be honest: this program behavior for these type of activities looks a little bit antique and embarrassing.

Therefore I thought of the following solution: Putting these activities in separate programs with no visual interfaces, which are initiated by the main program and closed after they are done. Because these processes might not responding to requests on info of their current status, progress info could be written into and accessed from a shared SQLite DB.

This approach should work and should be a sound workaround for Revolutions' deficit of having no multi-threading capabilities.

Maybe this could be turned into a more generic solution for dealing with Revolution limiting multi-threading capabilities.

Any Comments?

Best,

Frank

RE: 2D and Multidimensional Arrays in Revolution 1.8

trevordevore — Thu, 24 Jul 2008 14:11:53 GMT

If you need to use 2.x in your current project then I would suggest using commas to mimick a multi-dimensional array. For db records this works pretty well. Pseudo code:

Code:

put 0 into i
repeat through cursor
add 1 to i
put cursor column into theArray[i, column]
end repeat

put i into theArray["count"]

Now you can loop through the array like this:

Code:

repeat with i = 1 to theArray["count"]
put theArray[i, COLUMN]
end repeat