next »

[Snorri B.]

Hi.

Any news on this request?

This was about getting the name of the last action the user triggered, something like:

IF fgl_lastaction() = "accept" THEN

or

IF DIALOG.lastaction() = "accept" THEN

[Snorri B.]

Is this perhaps the wrong forum to ask questions like this?

[Reuben B.]

Hi Snorri,

As you are probably aware, I was a Genero user from 2002 to 2008 and heavy contributor to the old maillist list, and for the last two years I have been working for Four J's Asia Pacific.  So I have experienced both sides of the fence.  If you dig through the old mailing lists you will see there is an entry from me in 2004 asking for this feature as well so I believe it is something that should be there.

Is this the right forum? Yes. 

(The question could be asked, is the web based forum the best method for getting this type of input, the old mailing list we got 6000 posts a year, now we are lucky to get 1000, does entering a login/password and a number of mouse clicks reduce the input we get)

From my experience of being on both sides ...

Need to present a convincing case -  Show how/why you need the feature.  What you can't do without it.  How many lines of code you would save.  How does a competing development environment do the same thing?

Ease of 4gl compatability - FGL_LASTKEY() is deprecated and does cause issues for people migrating.   Show how someone can migrate more easily using FGL_LAST_ACTION() to replace FGL_LASTKEY()

Persistence, weight of numbers -  What can happen is people find a workaround and don't pursue it anymore.  The folder page issue is a case here.  In 2.30 you will have https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/NewFeatures.html#ensure-field-visible to solve that folder page issue.  Yes there was a workaround but we shouldn't need to use a 30 line function.  That is in their basically because of persistence and weight of numbers.  Hopefully summary lines in an array will make 2.30 as well.  So if any other uses think FGL_LASTACTION would benefit them, this forum is the opportunity for you to say so.

Portability - How will the feature work in GDC and in GWC.  Will it work on Windows/*nix/Mac platforms.  This particular request, how would you handle local actions, would it tell you if the last action was a paste, if so, how would that work in the GWC etc.

$$$ - It goes without saying but every new feature has a cost.  Not just the time coding it, it has to be documented, inserted into QA tests etc   I look at this and think it is a 5 minute job but then there is the other stuff to do as well.  What are the benefits to 4Js, will this help attract new customers, will this keep existing customers longer.

Reuben



 

[Stephen T.]

Reuben,
(IMHO) the lack of posting is nothing to do with having to log in etc, but more to do with the change of direction of the list.

The original list was brilliant as ALL issues appeared there - so you knew exactly what issues were there, which of those were causing the grief and the general direction the product was going. Now this forum is sanitised - all the issues being referred to support centres (which also appear to be cost centres). So this becomes a 'diluted' version of the original. Worse, where issues used to be open, now they are all hidden - you haven't a clue what has or hasn't been reported, what the state of any issue is (ie if it has been reproduced) - - and what, if anything, is being done about them.

What also then seems a nonsense, is that issues must be being repeated around the globe. IE common issues get reported to different support centres. OK, so the issues/questions should get logged - and the support centres should refer to a central repository - but isn't that what the original list was?

I can understand the reasoning behind keeping the developers away from support issues - but really was it beyond the wit of man to still have a central list where all issues/questions were logged/asked - and then the  issues picked up by local support centres to 'prove' before submitting as an actual issue to development? The issue number could then be put on the list - so all the users could then track that issue if they were interested.

This was all raised when the original list 'died'.

[Snorri B.]

IMO, the old mailing list was better in many ways, more traffic and response time quicker :-)

But back to to fgl_lastaction.
I am writing a routine that will be called VERY often in after field clauses. This routine does some fancy stuff which I will not derscribe in detail, but I want to know if the user has accepted the form. If so, this routine will return immediately

Code

function myAfterFieldFunc(...)
define ....
 
if fgl_lastaction() = "accept" then return ... end if
.
.
.
end function
 

Another aspect of this is we have some code like this:

Code

 on action refresh
        let action = "refresh"
        exit dialog
     on key (f3)
        let action = "refresh"
        exit dialog
 
     on action f4
        let action = "filter"
        exit dialog
     on key (f4)
        let action = "filter"
        exit dialog
     on action search
        let action = "filter"
        exit dialog
 
     on action insert
        let action = "insert"
        exit dialog
 
     on action other
        let action = "other"
        exit dialog
     on key (f5)
        let action = "other"
        exit dialog
     on action other1
        let action = "other1"
        exit dialog
     on action other2
        let action = "other2"
        exit dialog
     on action other3
        let action = "other3"
        exit dialog
     on action other4
        let action = "other4"
        exit dialog
     on action other5
        let action = "other5"
        exit dialog
 
 

It would be better to have:

Code

on action f4, other1, other2, .....
  let action = fgl_lastaction()
  exit dialog
 

Best regards,
-Snorri

[Reuben B.]

I'll start a seperate thread for the mail vs web debate...

I ws trying to rack my brain why I was after fgl_last_action() many years ago.

The first was all the code I had that said ...

Code

BEFORE FIELD fieldname
   IF field_not_active() THEN
      IF going_backwards() THEN -- function using fgl_lastkey() to determine direction
         NEXT FIELD PREVIOUS
      ELSE
         NEXT FIELD NEXT
      END IF
   END IF

... that all changed to use the active Attribute which was better in the long run but a little painful in the short term.

The other was for one of the reasons Snorri had.  Determining what INPUT ARRAY event, scroll down, delete row, accept the dialog etc. had triggered the AFTER FIELD, AFTER ROW block.  Look here https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/InputArray.html#CTRLBLOCK_EXECUTION and see what possible events can trigger the AFTER ROW !!!  I recall the ON CHANGE events helped a little.

With your last code snippet Snorri, are you aware that you can assign multiple accelerator keys to an action in the actionDefaults?

Code

<ActionDefault name="search" acceleratorName="f4" acceleratorName2="Control-F" >

Code

ON ACTION search
   LET action = "filter"
   EXIT DIALOG

You should only need one action block even if there are multiple ways of triggering that action, be it accel keys, toolbar, topmenu, buttons etc.

Although fgl_last_action would make dialog/popup menus shorter ...

Code

MENU "" ATTRIBUTES(STYLE="popup")
   ON ACTION yes
   ON ACTION no
END MENU
DISPLAY "User selected ", fgl_last_action()

... as these you typically put the action selected in a variable and exit.

Reuben