I've read here about the structure of signalR's response message :
for example
For PersistentConnection
{"C":"B,2CE|K,C|L,2|M,0|I,0|J,0","M":["foo"]}
Where
Persistent Response:
C - cursor
M - Messages
T - Timeout (only if true) value is 1
D - Disconnect (only if true) value is 1
R - All Groups (Client groups should be reset to match this list exactly)
G - Groups added
g - Groups removed
Question #1
What's wrong with sending only the message part ? why do i need all the "C" information ? The client only needs the message. A message number #N is not dependent with message number #N-1 (AFAIK) -- so I dont see the reason for this "C" section. ( and I assume Im wrong by missing something here).
Question #2
Even so , how can I understand what the tokens means ? I didn't see in the manual the "K,L,I,J,2CE" tokens.
Where / How can I understand what they are saying ? What if I don't want the server to send that info but only the message ?
Open Source has an often over looked feature. You can simply download the source and take a look around. By simply searching in the source for the string "R" I was able to find some of the information you are looking for.
Answer #2:
These shorthand property names directly map to the JsonSerialization of objects in SignalR.
HubResponse
S - State
R - Result
I - Id
E - Error
T - StackTrace
PersistantResponse
L - LongPollDelay
D - Disconnect
T - TimedOut
G - GroupsToken
Some of the others are not found in the current code base, and since the issue your referring to is 7 months old I would guess they have been refactored out.
Answer #1:
The metadata is important to how SignalR operates. The double edged sword of frameworks is that we offload the domain or what it solves to the framework and its creators, and we implicitly agree to let them be the domain expert. Sometimes that makes it a bit of a black box to use, if you want to see what each of these properties are actually used for download the source and follow the code. If for some performance reason you feel the need to trim out some of the code around what you determine to be extraneous fork the code and give it a shot.
Related
Issue with an old Biz app (not designed or developed by myself).
Its orchestration receives a particular message, which is then fed into a Decision shape. If the below logic applies (as directly copy/pasted from the shapes first branch expression), it should go that route.
msg_inputCanonical.CRUD == "D" && msg_inputCanonical.DbTable == "Staff"
I can see it terminating however (by using the Orchestration Debugger) as it follows the Else branch and eventually hits a terminate shape.
I've checked the msg_inputCanonical to confirm the values being passed through (as below extracted from the Tracked Message part), and can see it matches the string condition in accordance with its mapping - CRUD = ChOp;
<DbTable>Staff</DbTable>
<ChOp>D</ChOp>
There's nothing else that I can see that's influencing this re-route, so can anyone think of any quirks that might be causing it?
Note: I've amended the WCF-SQL Stored Procedure that generates the msg_inputCanonical as prior to this it wasn't trimming any of the CRUD/DbTable values and had been leaving deadspace in.
There is also a map that uses ltrim/rtrim functoids on the ChOp property, but again - can't see what harm trimming an already trim'd field would do.
I have also tried replicating the logic in a dev environment, and it works as expected going down the correct branch when I'm passing the message through.
I connected to clickhouse with tableau.
A query like this
select * from table_name limit 1
returns fields of the table, even though it should return raws.
image
If I try
select subs_key from table name limit 1
And click preview results
preview results
I get the error from above(except cnt is replaced with subs_key or whatever field I try to select)
How can I actually view table data?
Edit
There is a connection to the db, but no table is shown in available schemas.
EDIT 2
I managed to connect and get data from an oracle and mysql database, but while I am connected to click house, I can't see any data.
Don't quote me on this but I believe tableau has not official support for clickhouse, at least I could not find anything to contradict this, tons of people asking for it but nothing concrete.
There might some sort of beta integration that's not yet stable, hence you problem, but this is just blind guessing.
What I can recommend, if you really need a UI and can't just use the cl client is using tabix:
https://github.com/smi2/tabix.ui
Its fully open source for now and should be pretty easy and straight forward to learn, there might be the odd bits of Russian here and there, but I believe its getting debugged and translated at quite a good pace.
I get the same error message when I use DBeaver.
SQL Error [47]: ClickHouse exception, Code: 47, e.displayText() =
DB::Exception: Unknown identifier: default_type, e.what() = DB::Exception
If it's not a coincidence, then it's a JDBC driver bug.
I am trying to get user response with option of a b c d or e . I have configured a slot with these possible values and reading the slot in my nodejs. when a user responds with the option a, c,d,e are returned ok in intent.slots.Answer.value (although option "a" is returned as lower case in slot value and C,D and E returns in upper case) but the bigger issue is option "b" is returned with an extra dot (.) appended like this "b." While I can parse it out, I hate to patch it before I know what is causing it. I have done console.log of slot values before any manipulation and it is as per above description. has anyone experienced this?
The slot values you provide are getting used when the language model get's build. But there is no guarantee, that those values will be recognized by alexa and forwarded to your intent. It could by anything alexa understands. I guess alexa is considering a, c, d and e as words, but in the case of b, she understands it's a single letter (which get's returned as "B."). Why? Welcome to the mysteries of black box Alexa :)
I would clean the value like this:
value.toLowerCase().replace(/\./, '')
Building on unnu's answer... I would just use whole word options like One, Two, Three...
I want to customize the standard drill-down functionality and add a text parameter to the drill-down URL. I will then parse and use the parameter in the SysStartUpCmdDrillDown or EventDrillDownPoller class like the solution provided by Jan B. Kjeldsen in this question.
The standard drill-down link is dynamics://Target/?DrillDown_RecID/ :
dynamics://0/?DrillDown_5637230378/
In previous versions of AX it was possible to modify the RecId to custom text and parse the text once the client is started:
dynamics://0/?DrillDown_0MenuItemName=PurchTable&FieldName=PurchId&FieldValue=P000044
Unfortunately, in AX 2012 the RecId is checked before the client is started and if it is not a valid int64, the drill-down event is not sent to the client. Since it is not possible to change the RecId to anything other than an integer, #Alex Kwitny suggested in the comments at that same question that you can add the custom text to the drill-down target like this:
dynamics://0MenuItemName=PurchTable/?DrillDown_5637230378/
The problem I experience with this is that the link now gets confused about which instance to start.
If the target is equal to the value in the System Admin -> system parameters -> Alerts ->Drill-down target, a client with the correct server instance is started. When I append the text with my custom text, it always starts the default instance(Which could be different from the instance I intended to start). While this is not ideal, I could work around this issue.
The bigger problem is that it now always starts a new session of the default instance, even if a client session is already started. As far as I can see I cannot write X++ code to solve this issue since the server instance is determined before any code in the client is executed.
My question is this - How can I add custom text to the drill-down link while preserving the way the client instance is started: If a client for the instance is already open, it should process the link in the open client, and not start up a new client of the default instance.
You should probably come up with another solution as mentioned in this post, but there could still be a way.
The URL has two objects that can be modified:
dynamics://[Drill-down target(str)]/?Drilldown_[Int64]
According to you, if you modify the [Drill-down target], then it launches AX using the default client config, and that is behavior that you don't want. If you have a matching [Drill-down target], it'll launch in the open client window, which is behavior I can't confirm, but I'll take it at face value and assume you're correct.
So that means the only thing you can modify in the URL is [int64]. This is actually a string that is converted to an int64 via str2int64(...), which in turn corresponds to a RecId. This is where it gets interesting.
This work all happens in \Classes\SysStartUpCmdDrillDown\infoRun.
Well, lucky for you the ranges for the objects are:
RecId - 0 to 9223372036854775807
Int64 - -9223372036854775808 to 9223372036854775807
You can call minRecId() and maxRecId() to confirm this.
So this means you have -9223372036854775808 to -1 numbers to work with by calling URLs in this range:
dynamics://0/?DrillDown_-1
to
dynamics://0/?DrillDown_-9223372036854775808
Then you would modify \Classes\SysStartUpCmdDrillDown\infoRun to look for negative numbers, and fork to your custom code.
HOW you decide to user these negative #'s is up to you. You can have the first n-digits be a table id or a look-up value for a custom table. You can't technically use a RecId as part of that negative number because in theory the RecId could get up that high (minus 1).
I use twain 2.3 (TWAINDSM.DLL) in my application with HP Scanjet 200 TWAIN Protocol 1.9.
My TWAIIN calls are:
OpenDSM: DG_CONTROL, DAT_PARENT, MSG_OPENDSM
OpenDS: DG_CONTROL, DAT_IDENTITY, MSG_OPENDS
EnableDS: DG_CONTROL, DAT_USERINTERFACE, MSG_ENABLEDS
ProcessDeviceEvent: DG_CONTROL, DAT_EVENT, MSG_PROCESSEVENT
and as a result of the last call I allways get TWRC_NOTDSEVENT instead of TWRC_DSEVENT.
Could please someone help with this?
Once you use DG_CONTROL / DAT_EVENT / MSG_PROCESSEVENT, all messages from the applications message loop must be sent to the data source for processing. Receiving TWRC_NOTDSEVENT means the forwarded message isn't for the source so the application should process it as normal.
Keep forwarding all messages to the source until you receive MSG_XFERREADY which means there is data to transfer. Once the transfer is finished and you have sent MSG_DISABLEDS that's when you can stop forwarding messages to the source.
Twain is a standard, and when many company implement that standard, not all of them do the same way. Along the way to support Twain, we will learn and adjust the code to support all the different implementations.
I experienced this situation before, and this is my workaround:
Instead of placing (rc == TWRC_DSEVENT) at the beginning of code (will skip the following MSG_XFERREADY processing afterward) you can move the comparison to the end after MSG_XFERREADY processing, so that MSG_XFERREADY is always checked and processed.
(rc == TWRC_DSEVENT) is only to determine if we should forward the window message or not.
I don't know your specific situation. I ran into a similar issue because I called OpenDSM with a HWND/wId which is from another process. You should call OpenDSM with the HWND of
the active window/dialog which is owned by current process.