IHP's PostgreSQL implementation supports the POINT column type, and the IHP API has functions to parse and serialize, but I how to create form fields in a New and Edit View for it?
You could use a textField for that:
{(textField #location)}
But IHP currently has no support on how to turn the Point data type into a text format for the text field. You can manually add this by placing this type instance in your Application.Helper.View module:
module Application.Helper.View where
import IHP.ViewPrelude
-- Here you can add functions which are available in all your views
instance InputValue Point where
inputValue point = inputValue (get #x point) <> "," <> inputValue (get #y point)
Then a point will render like this inside the text field:
Related
When typing in an input field and forwarding #input = 'func', that function recieves an object containing among other things data and inputType.
When inputType is deleteContentBackward is there a Vue built-in way of getting that removed character? Because data is then null.
It's solveable otherwise, just wondering if there is a built-in place where it is registered.
I'm using the ABAP standard class cl_gui_textedit to read text from a textarea on my selection screen. But the result after calling the method get_textstream on the instance is empty.
Minimal working example:
REPORT z_mwe_textarea_bug.
DATA lr_edit TYPE REF TO cl_gui_textedit.
DATA lr_docker TYPE REF TO cl_gui_docking_container.
PARAMETERS p_dummy TYPE string DEFAULT 'just for testing'. ""// <--- need this to show selection screen.
INITIALIZATION.
CREATE OBJECT lr_docker
EXPORTING
ratio = 60.
CREATE OBJECT lr_edit
EXPORTING
parent = lr_docker.
lr_docker->dock_at( EXPORTING side = cl_gui_docking_container=>dock_at_left ).
START-OF-SELECTION.
DATA lv_text_from_textarea TYPE string.
lr_edit->get_textstream( IMPORTING text = lv_text_from_textarea ). ""// <-- why is lv_text_from_textarea empty??
You (or I, answering my own question) have to call cl_gui_cfw=>flush( ) afterwards. Like this:
lr_edit->get_textstream( IMPORTING text = lv_text_from_textarea ). ""// <-- lv_text_from_textarea still empty
cl_gui_cfw=>flush( ). ""//<-- now it's not empty anymore.
Disclaimer: Found the answer on abapforum.de but removed all the useless (and german) discussions and added a minimal working example to my question.
I need to define one dynamic selection field as required.
I created a transaction code with a starting variant.
For this variant in the attributes screen assignment, there is no "required field" option on dynamic selections, only "protect field".
Any idea how to implement this?
On variant attributes screen assignment there is not required field
option on dynamic selections
There is Required attribute in screen variant and it is perfectly usable for making regular field mandatory, and in dynamic selections too.
If you lack it, check your release or maybe your installation is corrupted. I don't believe it is tcode-dependent.
If you are talking about the Dynamic Selections, then you can only protect the fields. Example with demo program DEMO_LIST_OUTPUT (which is based on the F1S Logical Database):
You can only protect those fields against input, and all other attributes are deactivated (they are not implemented as you can see in subroutine MODIFY_SCREEN of program SAPLSSEL).
The only possible workaround to simulate a mandatory field is to implement ABAP code after the user has entered selections (or not). For instance, in the program DEMO_LIST_OUTPUT, you may add this ABAP code which checks that the screen field "Connection Number" contains a value when the user executes the program:
TABLES sscrfields.
AT SELECTION-SCREEN.
DATA dynsel TYPE rsds_trange.
CALL FUNCTION 'RS_REFRESH_FROM_DYNAMICAL_SEL'
EXPORTING
curr_report = sy-repid
mode_write_or_move = 'W'
IMPORTING
p_trange = dynsel
EXCEPTIONS
not_found = 1
wrong_type = 2.
DATA(connid) = VALUE spfli-connid(
dynsel[ tablename = 'SPFLI'
]-frange_t[ fieldname = 'CONNID'
]-selopt_t[ 1 ]-low OPTIONAL ).
IF sscrfields-ucomm = 'ONLI' AND connid IS INITIAL.
MESSAGE 'Flight Connection number is required' TYPE 'E'.
ENDIF.
NB: Tested with ABAP 7.52. Dynamic Selections can be implemented implicitly via Logical Databases (which are obsolete since ABAP 7.02 or 7.31) or explicitly by calling the function modules FREE_SELECTIONS_INIT and FREE_SELECTIONS_DIALOG.
I'm working on a Function Module to assist with dealing with included text with logic embedded. While looking into the way SAP handles SAPScript files and parses the logic I found a structure that is declared as so:
DATA BEGIN OF events OCCURS 100.
INCLUDE STRUCTURE ITCCA.
DATA: command LIKE BOOLEAN,
template LIKE BOOLEAN,
mask LIKE BOOLEAN,
END OF events.
This obviously works, as I can trace through it while it is running a print program. So I thought I would try a similar structure in my own code but even when I copied the code 1 for 1 like above I get an error during activation. The error is
"BOOLEAN" must be a flat structure. Internal tables, references,
strings and structures are forbidden as components.
Can someone explain to me why this structure is valid in one program and not mine?
To explain the actual effect: LIKE usually refers to a data object (an actual variable) on the right-hand side, not a data type. As you rightly discovered, once you provide a data object named BOOLEAN, that is used to construct the type. If a data object of that name is not present and you're not within a class or an interface, an obsolete variant of the LIKE statement will be triggered that also takes data types into account, but only allows for certain elements on the right-hand side - namely only flat structured objects or their components. LIKE DATATYPE-BOOLEAN should have worked. As usual, the error message is somewhat less than helpful.
It seems during my initial investigation I missed a declaration for the BOOLEAN type. In the STXC function group SAP decided to declare their own variable for boolean in a different include file like this:
data: boolean(1) type c.
I had originally assumed that they were doing this with the dictionary defined type which has a similar name and is a 1 character long string. What I also found is that if I were to change my structure declaration like this:
DATA BEGIN OF events OCCURS 100.
INCLUDE STRUCTURE ITCCA.
DATA: command TYPE BOOLEAN,
template TYPE BOOLEAN,
mask TYPE BOOLEAN,
END OF events.
My code would be valid because it would then be using the dictionary defined value. So either I have to add a declaration for my own definition of boolean so that I can use the LIKE keyword or I have to use the TYPE keyword to use the dictionary definition.
I need to call a function that has a table type as import parameter in a program. I thought about doing this with a selection screen but I can't use deep structures as parameters. When I 'TEST' that function module it shows me a thing where I can add multiple entries and submit everything in the end. Can I get something similar during the execution of a program?
edit: I have to offer a program that calls the function module create_skill_profile.
1
2
3
You can call the function module RS_COMPLEX_OBJECT_EDIT in your report for editing a complex structure. This is the same function module that is used for editing test data in the function module single test.
So, in your report, you could ask for the name of the desired type (if that has to be a dynamic one), and then, in start-of-selection, you can create a data object of this type and pass it to RS_COMPLEX_OBJECT_EDIT to let the user fill it.
A serious limitation of RS_COMPLEX_OBJECT_EDIT is that it can't handle sorted or hashed tables as input. So all the components of your complex structure, if they are of table kind, they have to be standard tables.
What I understand: You want to call a function module that requires a table as import parameter. The table's rows are filled from user input. The number of rows is dynamic.
Approaches:
1) use selection screen with predefined input fields and show/hide them dynamically via PAI (AT SELECTION-SCREEN (on xxx). LOOP AT SCREEN.) then build your table and call your function module on START-OF-SELECTION.
2) show editable ALV grid with table structure. Implement an application toolbar button or use SAVE button to let the user call your function module when he finished inserting his input.
I would defenitely prefer 2), although custom input validation is a bit tricky. But if the required user input is the same as ddic defined table structure the input validation happens automatically.