Posted 6 years ago by Luke Burt
Version: 2.1.0012
Avatar

Recently downloaded this app on my surface 2, to do some HTML /CSS writing but keep hitting a wall with saving bugs?

My general experience is this: open a working HTML /CSS combination, do 0 edits but re-save the HTML under a new name - something that was working, like an image breaks when loading it in IE (local files) despite 0 changes even being made..

problem happens with every app store editor tried, so seems to be something more Core OS /api related? They all break the same parts, very strange..

if i open up the file in notepad though and resave it, the file works as intended?

Also on a few occassions editing a HTML page, i'll delete a block of code, save it and it somehow doesn't do it properly - deleting one line out of 5 for example, so i have to close and reopen the file, otherwise this incorrectly deleted block stays in the file, but hidden from the code editor?

would appreciate any help, the fact it seems to happen on every metro editor (that supports html) makes me think its something im doing wrong? but im litteraly only resaving files without any edits...

Comments (11)

Posted 6 years ago by Luke Burt
Avatar

to add a few updates:

Seems to only affect local resources linked to within the html (external css had to be resaved under this app for it to load the css - images /objects however will not load)

Linking to an image on the web was fine, but as soon as it's linked to a local file it breaks?

saving in notepad under the same file after being broken by metro apps doesnt fix it, resaving as a new file does, however fix it.

it's a really odd and frustrating problem nonetheless

Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Luke,

That's really odd, we haven't seen that sort of thing happen at all.  Every time we have saved files, it's been spot on.

I can say that our code is using the standard asynchronous I/O routines in WinRT that Microsoft makes available to us, which is likely the same code that other editor apps use too.  Specifically we use the "IStorageFile.OpenStreamForWriteAsync()" method.  It shouldn't really matter what types of files are being saved. To us, it's all just a text file that we write out with the method above.  There isn't any special processing happening for CSS, etc. (at least on our end) when the save occurs.

If you are experiencing problems in all the editor apps, then you might be best off posing your question over in the Microsoft forums since perhaps someone there has heard of this happening.  You should remember that the file I/O in Windows 8 apps is all async too.  If you are saving to a networked drive (like SkyDrive or Box) then maybe something isn't finishing up correctly or in time (before the app shuts down) during that save process?  You could try saving to your local drive (if you aren't already) and see if that makes a difference.

Another thing I just thought of was perhaps something else is locking the file and preventing it from saving?  You mention that it's generally files that are linked to by something else.  So maybe a web browser or something else you are running is preventing the file from saving.  It's hard to say, just a thought.

[Modified 6 years ago]


Actipro Software Support

Posted 6 years ago by Geoffrey
Avatar

I am having the exact same issue.

  • I make 2 copies of the same HTML file in my local Documents directory
  • Both files open and display normally in IE
  • Open, then save one of the files using Code Writer, making no changes
  • The html saved by Code Writer no longer displays correctly in IE. Only the most basic text formatting displays.

I can diff or binary compare the two files and they are identical. Veiwing source within IE looks identical. If I copy the problem file to a new file, the issue goes away. I've checked all file attributes that I can think of and everything looks the same.

Modifying the html with Notepad and saving does not cause a problem.

Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Geoffrey,

As mentioned above, we use the standard WinRT I/O routines to save files, so instead of comparing to Notepad, I would ask that you see if you get the same results in another Windows Store editor app.  Luke seemed to find that all of them had the same issue, meaning that it's likely some issue core to WinRT itself.

We tried to repro this but still haven't been able to.  Can you give very exact steps to do so, including links to any files that you are opening, etc. so that we can try and get it to happen on our side?

Thanks!


Actipro Software Support

Posted 6 years ago by Geoffrey
Avatar

I haven't had much time to look at this the last few days, but I've discovered a bit more and the problem is related the character encoding being used to save the html file. I can 'fix' the Code Writer saved html file in Windows Notepad by doing "Save As" and selecting Unicode or UTF-8. Saving as ANSI in Notepad works as well - as long as the file was not already 'damaged' by Code Writer. By 'fix' or 'damaged' above, I simply mean whether the htlm+css is rendered as expected by IE 11.

Also, I was trying to do this using a Surface Pro 2, not RT and haven't got another "metro" text editor. The logical thing to do would be just use a desktop editor, but I'm curious if this particular problem is IE being too finicky, Code Writer not properly handling character encoding, or a Windows 8.1 New UI weakness... Or all three.

simple.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="css/test.css" rel="stylesheet" type="text/css">
</head>
<body>
<h1>Heading 1 Red/Small</h1>
<h2>Heading 2 Green/Medium</h2>
<h3>Heading 3 Blue/Large</h3>
</body>
</html>

 

 

test.css

/* test.css */

body{
background-color: #FFFFDD;
}

h1 {
font-size: 10pt;
color: Red;
}

h2 {
font-size: 15pt;
color: Green;
}

h3 {
font-size: 20pt;
color: Blue;
}

Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Geoffrey,

Thanks for the sample files. I tried opening them both in Code Writer, and then opening the HTML in IE.  I was able to make changes to the files fine and see them update in IE ok.  Please give exact steps, start to finish, on how you repro it with these two files.  And let us know if you are using the Metro IE or desktop.

Also if you think this might be some encoding issue, Code Writer lets you select the default encoding in settings and you also can modify it on a document by document basis.  You shouldn't really compare a desktop app to Code Writer though if trying to narrow down whether it's a Code Writer bug or a WinRT bug.  You really should try another metro editor app and see if the same thing happens when following your process there.


Actipro Software Support

Posted 6 years ago by Jeff Krans
Avatar

I have the exact same problem. I used Geoffrey's code from above and opened the html file in IE on my Surface RT and the styles initially displayed as expected. I then opened the html file in Code Writer and without making any changes, simply clicked save. After exiting out of the app and then attempting to open the html file once again in IE, the styles are lost and ignored by the browser. So far, I've experienced this same behavior with all of my html/css files. Along with the styling, image files are also ignored by the browser. This problem isn't specific to Code Writer however, as I've tested this same process with other editors such as Notepad RT and experience the same results. This leads me to believe its an IE/system setting somewhere with the Surface.

I've tried a number of different settings etc, but have had no success. Not exactly sure where to go at this point.

Thanks,
Jeff 

Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Jeff,

Hmmm... I'm not really sure what it could (we haven't been able to repro it yet, even on Surface Pro with IE) be but based on yours and others findings that it happens with all Windows Store editor apps, it seems like a bug in IE.  I would recommend contacting Microsoft on this via their IE and/or general WinRT platform product support.  It sounds like something on their end is going wrong.

I know you can't test this on Surface RT, but those with a Surface Pro, I'd be interested to know what happens if you have an editor like Code Writer working with files and then open the files in something like desktop Chrome instead.  I'm curious if the same issue happens there or not with similar repro steps (but excluding IE of course).


Actipro Software Support

Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi All,

I'm not sure if the problem mentioned in this other file save thread is related, but it might be.  Our file save routines basically go down one of two paths based on what character encoding option you have selected in the Settings:

  1. Automatic detection character encoding - A simple one-line method provided by Microsoft is used to save the file.
  2. Other character encoding - Another method where we write out to a stream that uses the encoding. However while researching the bug mentioned in the other thread we found that the main method Microsoft provides here for writing won't clear old contents of the file before the file write starts.  Thus if the saved text is smaller than the file's length, some old characters would remain at the end.  We found a workaround for this problem and have it ready to go for the next version.

I'm curious if you think the fix we just did for #2 might apply to the problems described in this thread or not.


Actipro Software Support

Posted 6 years ago by Geoffrey
Avatar

I'm not willing to put much more into this, but if I notice there has been an update I'll give it a try and post here whether my IE/CSS issue still exists. My current CW version: 2.2

Posted 6 years ago by Jeff Krans
Avatar

Hey guys, thanks for following up. Not sure if the character encoding issue is related or if the slated fix will correct the problem, but I'm anxious to try. I'm on CW version 2.2 as well.

Jeff

The latest build of this product (v3.3.0029) was released 8 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.