FWD » Core Development » User Interface

Image handling methods for buttons:

LOAD-MAGE-UP
LOAD-IMAGE-DOWN
LOAD-IMAGE-INSENSITIVE

Reproduce native 4GL behavior for loading/using images in buttons. Including dynamical loading.

The update evl_upd20150107a.zip has passed the main runtime regression cycle. Waiting for CTRL-C part to be completed.

Runtime testing completed. The results - 10696_65fcb0a_20150107_evl.zip. The 3-way tests was started in separate session.

The update is ready to be committed and distributed.

Good, go ahead.

The update evl_upd20150107a.zip has been committed in bzr as 10698.

Is there any behavior yet to be implemented?

Greg Shah wrote:

Is there any behavior yet to be implemented?

If we think about images processing here - handle image phrase in DEFINE BUTTON statement for size, stretching and options for:
LOAD-IMAGE* ( filename[, x-offset , y-offset , width , height]) related to offset and size.

I planned to return to this during working on image phrase.

The button widget image processing note. There are two places when we need to set/load image integration into button widget. First and simple one is using the LOAD-IMAGE*() methods. These methods set the image to button widgets already existed on the client side. And currently I have the proper solution for this case and it works fine.

The other place is handling the DEFINE BUTTON statement. The statement converts to the respective logical setImage*() methods on the server side. The main issue here is at the moment of server call setImage*() we do not have the button widget counterpart on the client side(even button constructor is not called). So we have nothing widget to set the image.

For now I see two possible solutions here.
1. Postpone the image loading to the moment when the button widget is created on the client side. This will require additional call from client to server to ask the image data. And as far as I understand this is not acceptable for performance reasons, right?
2. We create some storage on the client side to "cache" the images to apply when the client side widgets become ready to accept the images. This save from additional client-server conversation. This can be the static storage inside the ImageGuiImpl and will handle both button and image widgets. When the image transferred from this storage to real widget - the cached image can be removed to save some memory on the client side(images are memory hungry). As the image identifiers we can use widget ID and type(Up, Down, Insensitive or image widget owner) because the same image files can be used for all pictures to load.

So I'm inclining to approach #2. What do you think?

Postpone the image loading to the moment when the button widget is created on the client side. This will require additional call from client to server to ask the image data. And as far as I understand this is not acceptable for performance reasons, right?

Actually, it won't be an additional call because even in approach 2 there is a call to the client for every image, right? This approach 1 is really just a deferral of the call to the time when the button is created. I'm OK with this.

Constantin: is there a better way to implement the loading as part of the button creation/push to the client?

Greg Shah wrote:

Postpone the image loading to the moment when the button widget is created on the client side. This will require additional call from client to server to ask the image data. And as far as I understand this is not acceptable for performance reasons, right?

Actually, it won't be an additional call because even in approach 2 there is a call to the client for every image, right? This approach 1 is really just a deferral of the call to the time when the button is created. I'm OK with this.

Constantin: is there a better way to implement the loading as part of the button creation/push to the client?

If the image is loaded by 4GL right when the frame is defined, then is OK to load it and push it when the frame definition is pushed to the client. But if the image is loaded only when the frame (or button?) is realised, unless I've missed some discussion on the other image-related task, I don't think we know at this point the exact time when the image is pushed to the client, until we check this case: what happens if the PROPATH changes between the DEFINE BUTTON and the frame definition/view, so that now on the PROPATH there is another image file with the same name, but different contents (assuming relative paths are used)?

If image is really resolved and loaded at the frame definition, then I would just save it at the ButtonWidget on the server-side and ensure to push it to the client-side when the frame is realised. But can the button be part of more than one frame? can it show two images - if PROPATH changes - in different frames?

Postpone the image loading to the moment when the button widget is created on the client side. This will require additional call from client to server to ask the image data. And as far as I understand this is not acceptable for performance reasons, right?

Actually, it won't be an additional call because even in approach 2 there is a call to the client for every image, right?

Yes, but in approach 1 we have:
- try to load image, this is server->client call, if no widget at this time, return false
- ask the server for postponed image to load, client->server.
So in worse case we have 2 server<->client calls for the approach 1.

But if the image is loaded only when the frame (or button?) is realised, unless I've missed some discussion on the other image-related task, I don't think we know at this point the exact time when the image is pushed to the client, until we check this case: what happens if the PROPATH changes between the DEFINE BUTTON and the frame definition/view, so that now on the PROPATH there is another image file with the same name, but different contents (assuming relative paths are used)?

Eugenie: please determine the answer to this question.

Eugenie: please determine the answer to this question.

The answer is the moment when button is realized is the point when 4GL loads image from currently set PROPATH directories. So if we change the PROPATH to something that contains the file with same name but new content - the image will be constructed from new content.

OK, please take this into account in your design.

1. I think that the loadImage() methods should still be used by the converted business logic, even for this DEFINE BUTTON case. The reason is simple: before realization I expect that the loadImage() methods will also have their effect deferred. In other words, this is probably a common feature that must be handled by loadImage().

2. If the button is already realized, then the processing occurs just as it is coded today.

3. If the button is not realized, then the load is deferred until realization.

Had to modify CommonWidget/GenericWidget classes to add loadImage*() methods support to handle dynamically allocated image/button widgets case.

Code Review evl_upd20150127a.zip

I like it.

1. There are no real changes in ButtonWidget, just a history entry. I think that can be removed safely. :)

2. Please remember that we have a new policy for methods/attributes which are only available on a small number of widgets. I don't want the image loading methods to be added to CommonWidget, since only 2 widgets support these. Please create a separate interface (ImageSupport?) and implement that in ImageWidget and ButtonWidget. You will have to edit handle.java (unwrap method) and HandleCommon.java to add the new interface there.

3. Please do fix the problem in note 17.

4. What part of the changes were there for DEFINE IMAGE? I don't see any conversion changes.

1. There are no real changes in ButtonWidget, just a history entry. I think that can be removed safely. :)

OK. Done.

4. What part of the changes were there for DEFINE IMAGE? I don't see any conversion changes.

The rule to properly convert DEFINE IMAGE was included in my previous committed update: evl_upd2015019c. The runtime support is in setImage()/loadImage() for image widget classes. Is it answering to your question?

This update seems pretty close to something that can go into regression testing. Is there anything else needed except from the debugging you were going to do to confirm proper functioning?

I'm thinking about note 2 above. I agree, we need separate interfaces for something that support by several widgets only. Because current approach looks a bit not effective. Even more we actually need two more classes, one for image and button(for LOAD-IMAGE) and other - only for button(the rest LOAD-IMAGE*() methods).

So we can run testing now or postpone to the time the interface rework is ready. What do you think?

BTW, the dynamically loaded images works OK. Need to test dynamic frames as well.

So we can run testing now or postpone to the time the interface rework is ready. What do you think?

Do the rework now. When it is ready, post it. After a final code review, it will be into testing.

Code Review evl_upd20150128a.zip

It looks good. Please do get it tested.

It looks good. Please do get it tested.

OK. Starting the conversion testing stage(we have the rule changed).

Conversion testing completed. The codes are identical. Starting the runtime testing.

Finally I have got the main part completed without regression. Starting the CTRL-C tests.

The CTRL-C part completed without regression. 3-way tests was started in a separate session. The results file on shared directory is: 10725_5c96d7c_20150130_evl.zip.

And because the evl_upd20150128a.zip does not cross other recent updates made since testing was started I think it is safe to check in and distribute. Is it OK?

Normally, the answer would be yes. But right now we are in the middle of a number of conflicting updates that have ThinClient changes. Those need to be checked in first. I'll let you know when we can "unfreeze" this one.

Normally, the answer would be yes. But right now we are in the middle of a number of conflicting updates that have ThinClient changes. Those need to be checked in first. I'll let you know when we can "unfreeze" this one.

OK. Not a problem.

Sorry, there are 2 updates in front of you right now. Hynek's is first and then Constantin has one. Thanks for your patience.

The evl_upd20150202a.zip also merged with 10739.

Please go ahead and do one more round of testing, using evl_upd20150204a.zip. If it passes, you can check it in.

Please go ahead and do one more round of testing, using evl_upd20150204a.zip. If it passes, you can check it in.

OK. The conversion testing is in progress.

The conversion testing completed. The generated code is identical. Continue with runtime testing.

The runtime testing almost completed. The only issue is the GSO 269 test. It failed with two main cycles but passed as standalone. I guess it is OK. But to have more sure I'm going to start one more main round cycle because the failure is pretty strange - INVALID FACILITY CODE for H1 which is known as valid facility.

I appreciate that you are taking extra care. Thanks.

The testing completed. Results: 10742_5c96d7c_20150205_evl.zip. No regressions confirmed.

I've stopped the servers and going to check in and distribute the update.

The update evl_upd20150204a.zip has been committed in bzr as 10744.