How can i do some validation before I save using dyntoolbar Object?

[rolguin]

Hi,

Can someone give some examples how can I do validation before the Save Button it is pressed on dyntoolbar?

Thanks in advance for any examples.

Regards,

 

[RealHeavyDude]

• Are you talking about ADM2/Dynamics?
• What do you want to validate?
• What should trigger that validation?

From what you tell I could only speculate what is that you want to achieve.

Heavy Regards, RealHeavyDude.

 

[rolguin]

Hi Dude,

Thanks for the reply. Yes, I am talking about ADM2/Dynamics.

I have created in the same Smart Window: a SDO, a SDB and Smart Tool Bar.

The SDB is Enabled for any modification in the rows/fields. So, any modification the Save button from the Smart Tool Bar enables then I need to add a validation to verify if the Account is a existing Account.

I've tried to do a work around in the events for SDB like (ROW-LEAVE) but I am not really sure if it is the right place to put a validation.

Another problem is: in the fields of the SDB - How can I capture the keys like "escape"? I have to click in the bord (or ENTER or TAB) of the browser to leave the field BUT the "escape" does not work.


Regards,

 

[RealHeavyDude]

First I have to say that the SDB is not a good UI choice to update records. Second, such validation belongs into the transaction validation hooks of the SDO. Most likely you need to access the database to do such a validation and there should not be any code in a UI object that will bind it to a database. If you do that you will lose the possibility to run the application with AppServer - of which ADM2/Dynamics applications are capable of out-of-the box if you don't do something wrong ...

Therefore I have two recommendations for you:

1. Provide an SDV to update a single record. Then you can use a smart data field to visualize the accounts field as a lookup/combo-box to make sure the user can't put in invalid values.
2. In any case add the code to validate the account in the preTransaction validation hook of the SDO. Depending on the version of ADM2 or Dynamics you use they have different names. This is to make sure that nobody that uses the SDO to save data is able to bypass your business logic in case the UI doesn't restrict the users.

Heavy Regards, RealHeavyDude.

 

[rolguin]

Thanks for the quicly replie.

Ok, I got the idea.

When you say: "add the code to validate the account in the preTransaction validation hook of the SDO". What do you you mean with this? Shall I create a Trigger or a Fuction?

In the Smart Data Browser: Why I can't capture the "Escape" inside of the field?

Thanks,

 

[RealHeavyDude]

I'll take it from you question that you are not familiar with the functionality of the SDO.

The SDO provides several validation hooks which fire when they exist. In other words you just need to put an internal procedure with the name of the validation hook into your static SDO or its logic procedure. Now it's important to know whether you use Dynamics or the ADM2 ( Dynamics takes the ADM2 as its base and adds a lot on top of it ... ) and in case you use ADM2 whether you use the logic procedure or not in order to determine which of them are available to you:

Here's a list ( I think their names speak for themselves ):

• rowObjectValidate - this is a client-side validation hook because it lives in the client-side proxy of the SDO. Therefore you should only put code into it that does not need a database connection. For example you validate whether a field that must be populated is populated or not, a date lies in the future or in the past.
• createPreTransValidate, writePreTransValidate, deletePreTransValidate - these are only available with Dynamics or with ADM2 when you use the logic procedure and these are server-side. That means that you have access to the database but you are before a transaction is started - ideally to validate the validity of foreign fields.
• preTransactionValidate - this is available in plain ADM2 but, IMHO of course, you should use the above mentioned in favor of this one as you would need to branch your logic on the rowMode attribute of the rowObjUpd Temp-Table to know whether it's a creation, update or deletion ...
• createBeginTransValidate, writeBeginTransValidate, deleteBeginTransValidate - these are server side immediately after the transaction has been started. Ideally to automatically assign object identifiers.
• beginTransactionValidate
• createEndTransValidate, writeEndTransValidate, deleteEndTransValidate - these are sever-side immediately before the transaction ends. Ideally to automatically assign calculated values or values in dependent tables. ( But it's subject to discussion whether it would be better practice to call their SDO instead ...)
• endTransactionValidate
• createPostTransValidate, writePostTransValidate, deletePostTransValidate - these are server side immediately after the transaction has been committed. Ideally for example to print an order or send a confirmation email which should not be part of the transaction itself.
• postTransactionValidate

The functionality is such that a non-empty RETURN-VALUE will be interpreted as an error and the save process bails out immediately presenting the RETURN-VALUE as an error message to the user.

I think you'll get the meaning of these procedures.

As I've never used the SDB for update for the reasons I've mentioned - I can't tell you about the ESC key ...

Don't get me wrong, but: Working with the frameworks and not against them takes a lot of knowledge and experience. So don't take it lightly - neither should your boss - you will need education here, or, as an alternative hire an experienced consultant. By experienced I mean with ADM2 and/or Dynamics. Otherwise you will end up frustrated not achieving what you want.

Heavy Regards, RealHeavyDude.

 

[rolguin]

Hi Dude,

Thanks for your advice. I got it, You are right.
I will have to spend some time try to work better with ADM2 & Dinamics.

Kind Regards,