OBJECT Get Style Sheet not working in v16/17

Hi,

Anyone successfully using OBJECT Get Style Sheet in v16 and/or v17. In the context of FORM LOAD.

I just wrote some quick and dirty code looping over all objects in all table forms to see which objects don’t have a style sheet attached.
In 4D v16/17 I don’t get the expected result. Only a few objects seem to have a proper stylesheet attached. Except for Default and automatic. Though the majority should have a stylesheet as shown in the property pane of the form editor.
Tested on two different databases. Both of them originally started in v11.

In v15, one of those databases gives me 9569 objects with a custom style sheet. In v17, I get only 34!
Changing the style sheet to something else and back does not help.

Before I start digging into this, create a demo db, create bug report and discover it’s an already reported/fixed bug or standard behavior, I would like to hear some experiences of other developers.

Kind regards,
Koen

Hi Koen,

Indeed, the problem you describe is a bug.
Could you please send a bug report? The problem will be fixed as soon as possible.
For the moment, no workaround has been found for this case.

Thank you for your collaboration,

: Djompolo S. TANDJIGORA

Indeed, the problem you describe is a bug.
Could you please send a bug report? The problem will be fixed as soon
as possible.

Hi Dompolo,

Thanks for confirming the bug. I sent a bug report on TAOW as requested.
But I just wonder why I need to report this while the bug is already known and will be fixed asap.

And once more, and regularly requested by others (eg response of Patrick Emanuel on http://forum.4d.com/Post/EN/25818695/1/25818696): where can we poor developers find the necessary info about reported bugs? Not only the once reported by ourselves, but all others. Like in old times on this forum.

Kind regards,
Koen

Hi Koen, you’re right. I get nothing too.

Patrick

Hi Koen,

Yesterday I’ve discussed with the developer about your post, he confirmed that it’ a bug.
But the problem is not referenced, it’s the reason we’ve asked you to send a bug report, could you please send it?

Thanks and regards,

Hi Djompolo,

As I’m a 4D partner, the 4D forum says:
If you are a 4D Partner please use TAOW to report your issue or contact your local tech support. Our team will support you in describing the issue and creating a reproducible example which will speed up the process for resolution.

Yesterday I reported on TAOW so the 4D team will create a bug report. But as the developer already confirmed it’s a bug, wouldn’t it be better if he creates the bug report right away? Or directly ask the TAOW 4D team to do it?
Should be much faster then me reporting on TAOW and having local tech support pass it to 4D technician to create that same bug report. Right?

Maybe it’s my brain showing its age, but I can’t always follow the logic concerning bug reporting. But it might be much easier and save us valuable time if we would have proper access to all bug reports.

Kind regards,
Koen

: Koen VAN HOOREWEGHE

Maybe it’s my brain showing its age, but I can’t always follow the
logic concerning bug reporting. But it might be much easier and save
us valuable time if we would have proper access to all bug reports.

Not sure that is just specific to you :wink:
I beleive it is also the case for me

Patrick

Don’t even try to understand the 4D bug reporting system… :roll:

There is no logic in it, it is so complicate that no one understand it (even in 4D :!:slight_smile:

Every meeting with 4D and Partners, I plead for a unified AND UNIQUE entry = TAOW

Actually, there is so many entries that follow rules that no one undertand how to do.

Hi Manuel,

Yoiu’re right => One entry is enough

but we also need a view on all existing bugs (as partner) with the capability to search by keywords, function, command, …

Some “background” info:

it might happen that somebody from tech support asks on of our developers something as “if I do that and that, this happens. Is that a bug, a feature request, standard behaviour or the wrong approach?”. The developer says: “this should work, if that fail, report a bug”.

On that situation, there is no bug report or bug description, just a “this should work”.
There is nothing to search, it was just a guess from a developer based on the story.

Then we normally ask experienced customers for a bug report. This could be some lines of text (if partner), or fulfilling the minimum bug requirement (full description + example).

As partner, you can ask tech support to create their own example, sure.
They will do so - and if the description was enough to reproduce this example is used for the bug report.
When the bug is fixed they try their own example to verify the fix. And then you get the message “fixed”. Now you try your real application and might be disappointed “it still does not work for me, you did not fixed it!”.
Why? Because your application is doing something additional or something else, which was not described, so we did not knew.
So you need to wait again.

That is the reason why we ask for examples. Not a minimum requirement, still we ask. You can deny.

You wrote:
Tested on two different databases. Both of them originally started in v11.
In v15, one of those databases gives me 9569 objects with a custom style sheet. In v17, I get only 34!

So the different behaviour could be compatibility issue, happening somewhere in v11, 12, 13, 14. Creating the same on our own would fail.

This is why I think they ask for an example. Of course you are free to say no, try to reproduce first. And chances are high that it only happens in your structure. If you can upload it, it will save a lot of time - and make sure that you get the fix fitting to your situation.

Normally this is how it SHOULD works:

Step 1: WE open an incident (NOT a bug) in TAOW (we can give a small database to accelerate the next step)
Step 2: 4D SUPPORT study this incident and if necessary OPEN a BUG
Step 3: QUALITY correct this BUG

: Thomas MAUL

This is why I think they ask for an example. Of course you are free
to say no, try to reproduce first. And chances are high that it only
happens in your structure. If you can upload it, it will save a lot
of time - and make sure that you get the fix fitting to your
situation.

Hi Thomas,

This case is different. I immediately got the message my findings are confirmed as being a bug (thanks to Djompolo!). I’m not asked to provide examples.

If it is a newly discovered and unknown bug, I’ll be glad to take time to provide as many details as possible. Test with the newest builds, with older versions,… And create a minimal demo database reproducing the issue and describe all the necessary steps. No problem at all.

But I’m not prepared to probably lose many hours to do this for an already reported bug. That is why we developers (partners) absolutely need access to all reported bugs and their status (like it used to be a long time ago on this forum). It is quite frustrating to do the effort and after a few weeks get the response ‘bug already registered’.

Kind regards,
Koen

: Manuel PIQUET

Normally this is how it SHOULD works:

yes. Exactly this is the procedure…
(we have internally some more steps, like testing the fix, etc, but in short, yes).

: Thomas MAUL

I immediately got the message my findings are confirmed as being a
bug (thanks to Djompolo!).

yes, and sorry for misunderstanding.

International support has a more difficult job for different languages and different user groups.

Easier for us in German forum, when both sides speaks German.
But we also had misunderstandings, before we started to be very careful with language.
We stopped saying “bug report”, and strictly use “TAOW”. “Please open a TAOW case”.
If we think that a story reported has all information needed, we open a TAOW case in delegation for the partner and copy&paste the message there and answer in the public forum thread “moved to TAOW”.

Easier for us, as we are in charge for German partners. You are from Belgium, so customer from a distributor. Honestly, I don’t even know if your partner contract is signed with distributor or with 4D SAS.

So to avoid misunderstandings, if you are a partner and if you report something in a forum or other public medium (iNug, etc) and being told “file a bug” or “report a bug”, please read “open a TAOW case”.
Use the forum to discuss things, to ask other for help or advise (or give help), but do not see it as bug report or 4D support forum. We tried to handle bugs via forum and failed. Too many reports was uncomplete, not reproducible, and so never fixed in many years.

Use TAOW to open a case. The case is monitored and has a status (such as open or closed). As long it is not closed, it stays in the work list of an employee. Their job is to keep that list short.
Forum is discussion, not work list.

'bug already registered"

I know. Very frustrating.
And what’s even more frustrating: when the “already registred” is fixed, your’s is still open, because it only looked similar, but was different.
So for German Tech Support, we handle everything via TAOW. If a customer reports an issue and we think it is a bug, we report a new bug. We check with the newest build and if it is still there, we report a new bug. Don’t even check for existing ones.
Why? As more customers report about an issue, as higher is the priority, I guess that’s the same everywhere. But thats just one side.
When the “'bug already registered” is said to be fixed, our TAOW case is still open. We test the example from this customer, not the other one. We make sure that the real problem is fixed as well, or directly complain. This does not work if we would think “oh, somebody else had something similar, case closed” (do not try to build a real example for this customer, do not report a bug for this one).

It needs time to build an example? Yes. Oh, wait, usually no.
It needs time to understand the real problem. Upfront, the message is often fuzzy. That’s why searching fails. You think you saw something similar, but did not really understood the issue. Found something similar, but still different.
If I really understood an issue, I can build an example in 5 minutes. What takes hours is too know enough of the problem to reproduce, to build that example. And later that example is so important to verify if the problem (the real problem, not something similar), is really fixed.

Hi,

I fully agree with all you wrote, but why the bug list is not opened to partners because sometimes, we waist our time too to determine and identify correctly a bug, and this bug is already opened or corrected or on the way to. :frowning:

As Manuel said, start by Taow then, the process will determine if it is a bug or not is the start

But before that, the access to the current bugs list impacted 4D version will help us in some cases. It seems that this list is a dark box that us, developpers and partners, are not able to get access as viewer. What we are saying is we really believe that having access to this list could help us to do not waist time from the right hand, or waist more times in the other one (but should be not the standard case). :wink:

The others problems with MASTER BUG or “already registered bug” are that we can see the N° of this bug and that’s all !
We can’t confirm if it is the same bug
We can’t read his description (FYI we have access only our bugs descriptions)
We can’t know his actual status !!!

If a TAOW incident is affected to another MASTER bug please let us know his description AND his status :pray:

USER STORY: I have the case just yesterday, Open a TAOW case someone in 4D told me about an already open bug in the forum (we learn after by the support it is not the same bug !); other one affected a bug (not MASTER ?) in TAOW on my incident. Happily I can read the description and it was NOT the same as my incident.

Finally, the support see with me with TEAMVIEWER and open a NEW Bug… :roll:

Hi Koen,

I’ve sent the bug report : ACI0098645 : “OBJECT Get style sheet” command always returns the style sheet that has ID =0 instead of the assigned one.

The developer (Patrick) has fixed the issue, the correction will be available in the next versions.

Regards,