While testing App Studio 8.1.04 we discovered that editing an HTML or FEX file in an external text editor consistently triggered the dreaded 1 byte error - any file opened and saved in an external programmer's text editor truncates the file - all code in the file disappears in the repository. It seems editing in Notepad works, but Notepad is not made for developers, which is what I'm pretending to be...

Does anyone else have this issue?

This message has been edited. Last edited by: Francis Mariani,

I haven't attempted it yet, but would love to do such. How are you getting to the HTML via AppStudio after they took out the HTML tab?? I would love to know!

Thanks!

I've used it with no problems.

Used EditPlus.

What editor did you use ?

CoolGuy, one has to manipulate Windows - change the default program that HTML files open with (default is a web browser, must change to a text editor). Unfortunately, this setting can get reset after a reboot or when our systems support group pushes Windows update. This is the most ludicrous method of forcing a software to do something.

Waz, a colleague tested with NotePad++. EditPlus is my favourite Windows program, so, I am now compelled to install AppStudio and test with EditPlus.

Our Repository is in Oracle, perhaps the issues that people have depend on which DBMS is used.

Could be, ours is in SQL server.

I found, if I change the name of the file, through properties to TXT, I can edit it directly in AppStudio.. Screwy work around, but I put in a NFR last week to add "Edit in Text Editor" option for HTML files.

GavinL, you do realize that NFR will be buried under six feet of concrete?

I have this same issue with using an external text editor. I was attempting to use SublimeText 2 to edit my html pages, and I have one file that does not save correctly, and erases all data. Every other file saves fine from Sublime, and this certain files works fine from Notepad, and even Dreamweaver, but not Sublime. I opened a case and didn't get a solid solution. I ended up closing the case and just using DevStudio to use the built in text editor on that one file.

Regarding an internal text editor for HTML files: I opened a case on this subject on 29 July, 2014.

After some run-around with no resolution, the case was closed on 31 July.

I reopened the case on 30 September after I saw a comment on FocalPoint from David Glick, "If you see a need to edit an HTML Canvas file, please open a case and we will add the ability to the GUI." ([CLOSED] [over and out] App Studio v8.0.09 will apparently fix a lot of issues)

I asked for the case to be closed later in the day because I wasn't getting anywhere.

On 4 November, 2014, (despite the suggestion made by David Glick) the last comment in the case was "The final decision is that we are not allowing text editing of HTML pages in App Studio. So thank you for bringing this problem to our attention. But therefore, I will just close the case.".

Here we are in June 2015, testing AppStudio 8.1.04 to find editing in (so far, one particular) an external text editor does not work.

To add to Francis' attempts, Myself and a few others sat down with a few people from IBI at this years conference to discuss our concerns regarding the direction of the product. This issue was number one on my list and I am continuing to have this conversation over email regarding what happens in App Studio and why keeping the text editor is not only a good thing, but needed.

Up until Dan from IBI pointed out to me that App Studio V8.0.08 doesn't play well with Windows 7 (...), I couldn't create any HTML pages without it crashing. Since then I have been able to install app studio on a shared windows server and have been testing the HTML Canvas functionality. Installed on Windows Server, it has been pretty stable. I think I might have had one or 2 crashes, but nothing I could repeat. So I'll call them blips. But now that I have been able to do some actual testing, I'm still finding that one of the main reasons that I go to code all the time (the editor changing my sizes, injecting inline style commands that I don't want and not being to easily re-order my code so that it fits in the HTML Flow properly) are still evident. It took me about 30 minutes today to realize that on the CSS/JS tab, I have to toggle between CSS/JS... and once I realized that I had to toggle between to different views of that tab, it took me another 30 minutes to find where it was (Thats the only tab with that functionality... how does that make sense?).

So GavinL I think you should join our chorus on this subject, because I honestly believe for a healthy ecosystem, this functionality needs to be added back in. These half measures just makes development that much harder. And not everyone has the budget to get approval for a second HTML editor when you're already paying for one in the product (Granted Dreamweaver is much better then I would ever expect the editor to be). The big question is, how loud does the user base have to get to retain core functionality.

I agree with those here that it is very frustrating that IBI took out the ability to edit your HTML in AppStudio. Whomever it was made the decision based on self-interests...period.

It is absurd to not allow the real developers/real users to access the HTML. Those of us that should be accessing the HTML still need access to fix what the HTML Composer and other GUI-based tools of theirs mess up, etc. And it is so much faster and easier to add .css and .js to an HTML header than to jump around from dialog box/panel to dialog box/panel to simply get the tool to write 1 line of code. I am all for supporting the discussion and eventuality for IBI to get back on track, or to promote to others the need to move to a different BI solution if IBI's GUI dreams get even worse than they already have.

My opinion: Let them have 2 BI tool solutions. One for the kindergartners (non-tech users), and one for the grown-ups (tech users). Then everyone stays happy.

I have to admit that we have edited our HTML pages, to try and resolve issues that composer created. But be warned, it is very very easy to break it.

quote:

Originally posted by Waz:
But be warned, it is very very easy to break it.

It's also very very easy to verify that you did, and just as easy to revert your changes if you use a proper version control system.

One of the reasons I'm still using Dev Studio is precisely because it allows me to edit HTML files in the text editor.

quote:

Originally posted by Wep5622:
One of the reasons I'm still using Dev Studio is precisely because it allows me to edit HTML files in the text editor.

Same here.

I may never migrate to App Studio.

quote:

I may never migrate to App Studio

Unfortunately you'll have to when you start working with WF v8.2.01 or later - Dev Studio will be retired at that time.

quote:

Originally posted by Francis Mariani:

quote:

I may never migrate to App Studio

Unfortunately you'll have to when you start working with WF v8.2.01 or later - Dev Studio will be retired at that time.

Then that will be the time when the ranks of discontent customers will increase, the user base will deteriorate, and/or NO ONE will want to upgrade. Looking forward to the fireworks.

Heavily using App Studio V8.1.04

Desperately hoping that App Studio Matures a lot by V8.2

Hi Guy's

Its not a question of complaining its a question of providing solutions to issues that are best for everyone... If you don't like certain things in App Studio come up with an alternative that will make the product better. App Studio does have a lot of good things and with a positive spin and excellent suggestions, the product will mature and be a very good tool for developement...

Styling is easier, jquery is imbedded, function API calls are growing... So App Studio has more power and features that we can leverage.

So lets make a positive impact and make the product better. Keep the discussions alive and active, I think its great...

Thanks Barry

I just went back to Dev Studio, because there was no way to do what I needed to do with the UI alone. Removing the ability to access code from a developer isn't an option. Maybe if your trying to help non-developers, then UI is the only way, but do not remove our code access as that only makes our job harder. Make the developers job harder, puts pressure on our managers to move a different direction, which means, you lose clients. Not a good direction for anyone.

Which is why I have an NFR ticket open to have "Open in Text Editor" added. #21603539

This message has been edited. Last edited by: GavinL,

quote:

On 4 November, 2014, (despite the suggestion made by David Glick) the last comment in the case was "The final decision is that we are not allowing text editing of HTML pages in App Studio. So thank you for bringing this problem to our attention. But therefore, I will just close the case.".

I missed your message on this Francis.. David came to our company and started talking about this as well and I just laid it out for him. He will have to change his mind or cost IBI a lot of money by not doing so. BTW, that's not the final decision so hope isn't lost yet.

BarryS: "If you don't like certain things in App Studio come up with an alternative that will make the product better."

Me: alternative = putting back in the ability to access and edit the HTML.

GavinL: "I just went back to Dev Studio, because there was no way to do what I needed to do with the UI alone. Removing the ability to access code from a developer isn't an option. Maybe if your trying to help non-developers, then UI is the only way, but do not remove our code access as that only makes our job harder. Make the developers job harder, puts pressure on our managers to move a different direction, which means, you lose clients. Not a good direction for anyone."

Me: I am having the same experiences at my company. Quite frequently I have to let my project manager know about some limitation or bug AppStudio or some other IBI product is having that makes him and I 2nd guess our choice to use IBI as our BI solution. We really need literal access to the heart of the projects (code) we develop using IBI's products. The GUI is nice, but don't make it a replacement for what needs to be/should be accessible to the professionals. I've had a case open for almost 2 months about a property that doesn't work in AppStudio's HTML Composer product. I can't hard code it myself (providing my application with a fix while they take their time getting their properties panel working) because they won't give us access to the code.

AppStudio is a major leap forward from what DevStudio was/is, but it is still very much a beta product in my eyes, with a major handicap that needs to be mended (no HTML editing of any of your projects).

Also, the BIP is still very much a new thing with much room for improvement.

I'm glad you told us that you spoke to David on this at your company and gave him insight on the severity of this misstep of theirs. I really hope they put the HTML editing back in.

quote:

Originally posted by GavinL:
I just went back to Dev Studio, because there was no way to do what I needed to do with the UI alone. Removing the ability to access code from a developer isn't an option. Maybe if your trying to help non-developers, then UI is the only way, but do not remove our code access as that only makes our job harder. Make the developers job harder, puts pressure on our managers to move a different direction, which means, you lose clients. Not a good direction for anyone.

Which is why I have an NFR ticket open to have "Open in Text Editor" added. #21603539

Maybe if all of us open a NFR, IBI will get the message. I think they vastly over estimate how many end-users use their tools. I have almost 2000 end-users and the number that use any IBI tool to develop a report is 0.

Ok, I've talked to IBI and here is the issue.. They have had customers that have modified the IBI code within the HTML code and after a patch, it no longer worked. It took IBI a lot of time to figure out what happen.

So here is what we have to do, if we want this to work, we have to come up with a professional way to make this work for both of us.

Here is my first suggestion
Today, there is a Design and JavaScript TAB. Instead, create a tab for Design, one for Text, one for JavaScript, and one for IBI Code. Have a propitiatory HTML tag, so IBI knows where their IBI code sits and where to assemble it all together. As developers we know, not to mess with this tag or our HTML's will not interact as they should. It was suggestion to make the IBI code read-only, but I suggest NO. Some focus developers would rather change code than go through the UI, just because it's faster.

Someone come up with a better way.

This message has been edited. Last edited by: GavinL,

GavinL,

Its actually simpler then that. I'm sure you've noticed that there is the Import HTML button when you start a new page in the HTML Canvas? What do you think that does.... Its basically a compiler. It checks to make sure the the code will actually work. All IBI needs to do to make this work for every one is when we switch back from HTML to the GUI, run that compiler check. If it checks out then everything is fine and open the gui. If it doesn't check out then give us that annoying message that they give us today when we edit in HTML.

That message by the way. All it is, is a character check. It says I used to be 200 characters, now i'm 201 characters, so something was changed, I'm going to throw up a message and scare you.

To make matters worse, IBI intentionally removed the carriage returns from their code to make things MORE difficult for users to read the code.

All of these changes have been intentional and planned changes to make writing in code more difficult for us developers. IBI has known of other ways to do this that appease both their needs and our wants, and have intentionally decided to go the direction of making things more difficult.

I have a conversation scheduled with the correct people, who can affect the changes that we are talking about, on Friday. I'm hoping to have ears that are willing to metabolize the things that I bring to the conversation.

By the way, IBI is actually following this thread very carefully and have been watching the forums. They are well aware of the complaints that we are raising and the issues we have presented. This is why 5 of us were able to meet with IBI over this issue at summit, and why I have been in email communication with them in regards to this ever since then. All of the smoke of "Provide us a better solution" is just smoke to try to deflect the situation.

Even if something positive were to happen, it would occur in some distant version, so all the suggestions we make will be good for future generations to enjoy.

quote:

Originally posted by GavinL:
Ok, I've talked to IBI and here is the issue.. They have had customers that have modified the IBI code within the HTML code and after a patch, it no longer worked. It took IBI a lot of time to figure out what happen.

So here is what we have to do, if we want this to work, we have to come up with a professional way to make this work for both of us.

Here is my first suggestion
Today, there is a Design and JavaScript TAB. Instead, create a tab for Design, one for Text, one for JavaScript, and one for IBI Code. Have a propitiatory HTML tag, so IBI knows where their IBI code sits and where to assemble it all together. As developers we know, not to mess with this tag or our HTML's will not interact as they should. It was suggestion to make the IBI code read-only, but I suggest NO. Some focus developers would rather change code than go through the UI, just because it's faster.

Someone come up with a better way.

I was told by IBI similar, but just because 1+ customers were dumb enough to modify the IBI-generated code, doesn't make a good enough case to eradicate access to all HTML. That's just laziness on their part. I like your idea GavinL that they should add back in the HTML tab next to the Design, Parameters, and Embedded JavaScript/CSS tabs that are there now. I don't think they need an entirely separate tab for their tool generated code. They just need to put a comment line/block above and below their code warning about the consequences of messing with it. Then it is on the customers if they are dumb enough to alter it. But leave access to the rest of the HTML! Those in charge of this at IBI would do well to try and build an ASP.Net app in Visual Studio and take note of how they manage the GUI-generated code sections. The tool allows for #region tags to be placed above and below the GUI-generated code that adds the ability to minimize it out of view out of mind. Whether it is minimized or expanded, there is sufficient warning in comments around the minimized code warning the user not to mess with it. But the rest of the HTML, etc. is still accessible to the user.

One can easily muck up a GUI built graph or report and yet we're able to edit them via an internal/external text editor - why aren't these file types restricted as well?

quote:

Originally posted by Francis Mariani:
One can easily muck up a GUI built graph or report and yet we're able to edit them via an internal/external text editor - why aren't these file types restricted as well?

I bet that was probably the next set of dumb decisions in queue to be made in regards to AppStudio. Then there would be even bigger backlash from their customers.